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

[Remi Forax]

----- Mail original -----
> De: "Rafael Winterhalter" <rafael.wth at gmail.com>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Dimanche 13 Juin 2021 22:28:33
> Objet: JEP 411: Deprecation with removal would break most existing Java libraries

> 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.

Can you tell us about more about the scenarii where people are relying on the uses of doPrivileged() by ByteBuddy ?

> 
> 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.

In my opinion, the best way to deal with that is to have two codes one which is compatible with an AccessController.doPrivileged and one without it, using a multi release jar.
I can see a Maven/Gradle plugin that takes a code that uses an AccessController and generate a new code with a higher Java version that remove the calls to AccessController,
as a kind of forward port.

But we are not yet there, AccessController has to be removed first.

> 
> 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.

I guess the real question is when those classes will be removed.
If it's after several LTS releases, nobody will care. If it's tomorrow, that's another story.

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

regards,
Rémi