All Implemented Interfaces:
Direct Known Subclasses:
PermissionsHash, Permissions, PropertyPermissionCollection, BasicPermissionCollection, CryptoPermissions, KrbServicePermissionCollection, UnsupportedEmptyCollection, MBeanServerPermissionCollection, KrbDelegationPermissionCollection, AllPermissionCollection, CryptoAllPermissionCollection, SocketPermissionCollection, FilePermissionCollection, UnresolvedPermissionCollection, CryptoPermissionCollection
With a PermissionCollection, you can:
When it is desirable to group together a number of Permission objects
of the same type, the
newPermissionCollection method on that
particular type of Permission object should first be called. The default
behavior (from the Permission class) is to simply return null.
Subclasses of class Permission override the method if they need to store
their permissions in a particular PermissionCollection object in order
to provide the correct semantics when the
PermissionCollection.implies method is called.
If a non-null value is returned, that PermissionCollection must be used.
If null is returned, then the caller of
is free to store permissions of the
given type in any PermissionCollection they choose
(one that uses a Hashtable, one that uses a Vector, etc).
The PermissionCollection returned by the
method is a homogeneous collection, which stores only Permission objects
for a given Permission type. A PermissionCollection may also be
heterogeneous. For example, Permissions is a PermissionCollection
subclass that represents a collection of PermissionCollections.
That is, its members are each a homogeneous PermissionCollection.
For example, a Permissions object might have a FilePermissionCollection
for all the FilePermission objects, a SocketPermissionCollection for all the
SocketPermission objects, and so on. Its
add method adds a
permission to the appropriate collection.
Whenever a permission is added to a heterogeneous PermissionCollection
such as Permissions, and the PermissionCollection doesn't yet contain a
PermissionCollection of the specified permission's type, the
PermissionCollection should call
newPermissionCollection method on the permission's class
to see if it requires a special PermissionCollection. If
returns null, the PermissionCollection
is free to store the permission in any type of PermissionCollection it
desires (one using a Hashtable, one using a Vector, etc.). For example,
the Permissions object uses a default PermissionCollection implementation
that stores the permission objects in a Hashtable.
Subclass implementations of PermissionCollection should assume
that they may be called simultaneously from multiple threads,
and therefore should be synchronized properly. Furthermore,
Enumerations returned via the
elements method are
not fail-fast. Modifications to a collection should not be
performed while enumerating over that collection.
|Method from java.security.PermissionCollection Summary:|
|add, elements, implies, isReadOnly, setReadOnly, toString|
|Methods from java.lang.Object:|
|clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait|
|Method from java.security.PermissionCollection Detail:|
abstract public void add(Permission permission)
abstract public Enumeration<Permission> elements()
abstract public boolean implies(Permission permission)
public boolean isReadOnly()
By default, the object is not readonly. It can be set to
readonly by a call to
public void setReadOnly()
public String toString()
super.toString() ( // enumerate all the Permission // objects and call toString() on them, // one per line.. )