Hi,
One thing we haven't discussed historically because it only came up fairly recently, is the removal of the security manager in Java SE for local code-based security checks.
Jakarta Authentication uses a number of them, e.g.
/**
* The SecurityPermission, with name {@link #GET_FACTORY_PERMISSION_NAME}, that is used to authorize access to the
* getFactory method.
*/
public static final SecurityPermission getFactorySecurityPermission = new SecurityPermission(GET_FACTORY_PERMISSION_NAME);
/**
* The SecurityPermission, with name {@link #SET_FACTORY_PERMISSION_NAME}, that is used to authorize access to the
* setFactory method.
*/
public static final SecurityPermission setFactorySecurityPermission = new SecurityPermission(SET_FACTORY_PERMISSION_NAME);
/**
* An instance of the SecurityPermission (with name {@link #PROVIDER_REGISTRATION_PERMISSION_NAME}) for use in
* authorizing access to the update methods of the factory implementation class.
*/
public static final SecurityPermission providerRegistrationSecurityPermission = new SecurityPermission(PROVIDER_REGISTRATION_PERMISSION_NAME);
These are used on the server to check whether the code has code-level permission to set or even get a factory.
Such checks are then carried out by code such as this:
private static void checkPermission(Permission permission) throws SecurityException {
SecurityManager securityManager = System.getSecurityManager();
if (securityManager != null) {
securityManager.checkPermission(permission);
}
}
What shall we do with this?
Options are:
1. Do nothing, ignore the issues until it really breaks (when the type is actually removed from SE)
2. Add an @deprecated javadoc annotation, explaining it will go away (users don't have to do anything, since it's used internally by the API)
3. Just outright remove it
Thoughts?
Kind regards,
Arjan Tijms
