JEP 411: Deprecation with removal would break most existing Java libraries

[Peter Firmstone]

Binary compatibility only?

Security.getSecurityManager() always returns null.

Security.setSecurityManager() always throws a SecurityException 
(compatible because existing SecurityManager is allowed to prevent the 
call from succeeding).

SecurityManager constructor always throws a SecurityException 
(compatible because existing SecurityManager is allowed to prevent the 
call from succeeding).

Remove all methods from SecurityManager, no instances will be created, 
so methods will not be resolved, still binary compatible.

For Policy, retain methods and constructor, throwing appropriate 
exceptions, eg SecurityException or NoSuchAlgorithmException. Note that 
constructor will throw no exception, the exception will be thrown when  
attempting to set Policy.

Remove PolicyFile implementation.

Leave PolicySPI as is, but don't load them.

The first step would be to provide low level JDK hooks that allow for 
equivalent functionality to be implemented, back-porting to all long 
term releases, while leaving SecurityManager unchanged.

Then change SecurityManager prior to next LTS version (Java 23) to 
binary compatible only.  Then prior to the next LTS version (Java 29), 
remove it.

Maintained software will have had plenty of time to update and be 
compatible across all supported Java releases, provided appropriate JDK 
hooks are provided, only unmaintained software will still require it and 
unmaintained software will still run on unmaintained Java releases in 
VM's with unmaintained OS's.

Peter.

On 14/06/2021 6:37 pm, Alan Bateman wrote:
> On 14/06/2021 08:35, Peter Firmstone wrote:
>>
>> I wouldn't want to see SecurityManager and Policy be neutralized, 
>> it's better to remove it and fail early so people update their 
>> software, there's a risk they may update without realizing it's no 
>> longer fully functional.   Get rid of the baggage so people can start 
>> fresh with better practices.
>>
> I think the context for the question is libraries that want to be able 
> to compile to an older JDK release and work with a very wide range of 
> JDK releases.
>
> Many libraries do not play well with a SM. They don't execute actions 
> that require permission checks in privileged blocks and will often 
> need to be granted AllPermission. This may have knock on impact to the 
> components that call into these libraries, maybe they end up needing 
> to be  granted AllPermission too. Add callbacks or hand-off between 
> threads to the picture and it can become farcical. If the library code 
> isn't calling System.getSM or invoking AccessController.doPrivileged 
> then it probably won't care if these APIs are degraded or removed.
>
> There are some libraries where the maintainers have put effort into 
> working with a SM. Code in the library may use System.getSM, or doPriv 
> or limited-doPriv. It may document the permissions that it requires 
> and be helpful to someone assembling an application and creating its 
> policy file. This JEP is mildly disruptive in that there will be 
> warnings at compile-time or testing JDK 17+. If some future JDK 
> releases degrades some of these APIs then it may be a bit more 
> disruptive, maybe tests that try to set a SM will fail or need to be 
> skipped. It might be that a library uses an exotic API that doesn't 
> degrade in a sensible way and maybe that will be a bit more 
> disruptive. Further out again, if the APIs are actually removed then 
> it will be disruptive for libraries that want to support the 
> possibility of being deployed with a SM on an older release. That may 
> require some refactoring and the use of a MR-JAR as Remi mentioned.
>
> -Alan