----- Mail original ----- > De: "Rafael Winterhalter" <rafael....@gmail.com> > À: "core-libs-dev" <core-libs-dev@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
