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

[Rafael Winterhalter]

I am currently looking into how I should address JEP 411 in my library Byte
Buddy and I find it rather challenging. The problem I am facing is that I
know of several users who rely on the security manager in their Java 8/11
applications. I would like to continue to support those users' use cases as
long as I support Java versions that contain the security manager, which
will be for many years to come. At the same time, I would like to address
the announced removal of the API and make sure that Byte Buddy can work
without it prior to the deadline when the library in its current state
would no longer link.

>From my understanding of the intention of JEP 411, the API was supposed to
be stubbed – similar to Android’s stubbing of the API - rather than being
removed. However, with the announced deprecation for removal of
AccessController and SecurityManager, I understand that I would need to
fully remove the dispatching to work with future Java versions.

Furthermore, it is difficult to create a working facade for dispatching to
the security manager only if it is available. Methods like
AccessController.doPrivileged are caller sensitive and by adding a utility
to a library, this utility would leak to any potential user. It would
therefore require package-private dispatchers for any relevant package,
which would lead to a lot of copy-paste to retain backwards compatibility
(given that a library cannot assume to be run as a module).

Finally, removing the API would mean that Byte Buddy versions of the last
ten years would no longer link in future JDKs. For Byte Buddy where new
Java versions often require an update, that might not be a big issue but
many other libraries do support the API, I don’t feel it would be a rather
severe restriction and cause unnecessary breakage if API is removed, rather
than stubbed. I am thinking of libraries like Netty here which are rather
omnipresent and would suddenly no longer link, a concept that is unlikely
intuitive to a lot of developers.

Therefore, my question is: should SecurityManager, AccessController and the
Policy APIs really be deprecated for removal? Rather, I think that the APIs
should be deprecated, but be retained with stubbed implementations.
System.getSecurityMananger would then always return null.
System.setSecurityManager on the other hand could be deprecated for
removal. This way, existing code could continue to work as if the security
manager is not active, which already is the common scenario and would not
cause any disruption at the small price of keeping a handful of some
stubbed classes.

Thanks for advice on how this is intended to be handled by library
developers like me.
Best regards, Rafael