A Policy object is responsible for determining whether code executing in the Java runtime environment has permission to perform a security-sensitive operation.
There is only one Policy object installed in the runtime at any given time. A Policy object can be installed by calling the {@code setPolicy} method. The installed Policy object can beobtained by calling the {@code getPolicy} method.
If no Policy object has been installed in the runtime, a call to {@code getPolicy} installs an instance of the default Policyimplementation (a default subclass implementation of this abstract class). The default Policy implementation can be changed by setting the value of the {@code policy.provider} security property to the fully qualifiedname of the desired Policy subclass implementation.
Application code can directly subclass Policy to provide a custom implementation. In addition, an instance of a Policy object can be constructed by invoking one of the {@code getInstance} factory methodswith a standard type. The default policy type is "JavaPolicy".
Once a Policy instance has been installed (either by default, or by calling {@code setPolicy}), the Java runtime invokes its {@code implies} method when it needs todetermine whether executing code (encapsulated in a ProtectionDomain) can perform SecurityManager-protected operations. How a Policy object retrieves its policy data is up to the Policy implementation itself. The policy data may be stored, for example, in a flat ASCII file, in a serialized binary file of the Policy class, or in a database.
The {@code refresh} method causes the policy object torefresh/reload its data. This operation is implementation-dependent. For example, if the policy object stores its data in configuration files, calling {@code refresh} will cause it to re-read the configurationpolicy files. If a refresh operation is not supported, this method does nothing. Note that refreshed policy may not have an effect on classes in a particular ProtectionDomain. This is dependent on the Policy provider's implementation of the {@code implies}method and its PermissionCollection caching strategy.
@author Roland Schemers
@author Gary Ellison
@see java.security.Provider
@see java.security.ProtectionDomain
@see java.security.Permission
@see java.security.Security security properties