61 * calling {@code setPolicy}), the Java runtime invokes its
62 * {@code implies} method when it needs to
63 * determine whether executing code (encapsulated in a ProtectionDomain)
64 * can perform SecurityManager-protected operations. How a Policy object
65 * retrieves its policy data is up to the Policy implementation itself.
66 * The policy data may be stored, for example, in a flat ASCII file,
67 * in a serialized binary file of the Policy class, or in a database.
68 *
69 * <p> The {@code refresh} method causes the policy object to
70 * refresh/reload its data. This operation is implementation-dependent.
71 * For example, if the policy object stores its data in configuration files,
72 * calling {@code refresh} will cause it to re-read the configuration
73 * policy files. If a refresh operation is not supported, this method does
74 * nothing. Note that refreshed policy may not have an effect on classes
75 * in a particular ProtectionDomain. This is dependent on the Policy
76 * provider's implementation of the {@code implies}
77 * method and its PermissionCollection caching strategy.
78 *
79 * @author Roland Schemers
80 * @author Gary Ellison
81 * @see java.security.Provider
82 * @see java.security.ProtectionDomain
83 * @see java.security.Permission
84 * @see java.security.Security security properties
85 */
86
87 public abstract class Policy {
88
89 /**
90 * A read-only empty PermissionCollection instance.
91 * @since 1.6
92 */
93 public static final PermissionCollection UNSUPPORTED_EMPTY_COLLECTION =
94 new UnsupportedEmptyCollection();
95
96 // Information about the system-wide policy.
97 private static class PolicyInfo {
98 // the system-wide policy
99 final Policy policy;
100 // a flag indicating if the system-wide policy has been initialized
|
61 * calling {@code setPolicy}), the Java runtime invokes its
62 * {@code implies} method when it needs to
63 * determine whether executing code (encapsulated in a ProtectionDomain)
64 * can perform SecurityManager-protected operations. How a Policy object
65 * retrieves its policy data is up to the Policy implementation itself.
66 * The policy data may be stored, for example, in a flat ASCII file,
67 * in a serialized binary file of the Policy class, or in a database.
68 *
69 * <p> The {@code refresh} method causes the policy object to
70 * refresh/reload its data. This operation is implementation-dependent.
71 * For example, if the policy object stores its data in configuration files,
72 * calling {@code refresh} will cause it to re-read the configuration
73 * policy files. If a refresh operation is not supported, this method does
74 * nothing. Note that refreshed policy may not have an effect on classes
75 * in a particular ProtectionDomain. This is dependent on the Policy
76 * provider's implementation of the {@code implies}
77 * method and its PermissionCollection caching strategy.
78 *
79 * @author Roland Schemers
80 * @author Gary Ellison
81 * @since 1.2
82 * @see java.security.Provider
83 * @see java.security.ProtectionDomain
84 * @see java.security.Permission
85 * @see java.security.Security security properties
86 */
87
88 public abstract class Policy {
89
90 /**
91 * A read-only empty PermissionCollection instance.
92 * @since 1.6
93 */
94 public static final PermissionCollection UNSUPPORTED_EMPTY_COLLECTION =
95 new UnsupportedEmptyCollection();
96
97 // Information about the system-wide policy.
98 private static class PolicyInfo {
99 // the system-wide policy
100 final Policy policy;
101 // a flag indicating if the system-wide policy has been initialized
|