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
