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

[Alan Bateman]

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