<div dir="ltr"><div>One example for a currently necessary "doPrivileged" are Java agents where a class loading triggers agent code where the agent shares the stack with any code that loads a class for the first time. Otherwise, Byte Buddy wraps anything that might require privileges as privileged action to allow setting a policy that gives Byte Buddy for example access to class loaders, system properties or other things that the security manager currently checks. There's many uses of the security manager throughout the library, in the spirit of the API's invention.<br></div><div><br></div><div>I could, of course, rip this code out of the library. But this would make it impossible for users that choose to use the functionality for now to update their dependency. This would certainly hinder a smooth transition as library maintainers will always have people drag at both ends of the JDK version range. After all, Java 8 is supported for another decade. Multi-release jars are neither a feasible option. They are not globally supported by all class loaders, and would require me to add a copy of an adjusted class file for any Java version prior to the removal version or upwards from there. I don't think that this should be addressed by tooling if keeping deprecated skeletons of the API can so easily avoid this entire problem for all libraries without the need to chase down maintainers.<br></div><div><br></div><div>Therefore, I really think that the SecurityManager and AccessController APIs should remain as skeletons and be deprecated, but not be marked forRemoval, especially without a clear roadmap for the actual removal forward. And while I appreciate the clean up effort - I do think the SecurityManager deprecation and feature removal is a right decision - I find the attempt to remove this API will  cause unnecessary breakage and cause thousands of libraries to become unlinkable on future VM, without a clear need for it. Discovering this breakage would also require manually scanning the content of each library and affect all the big names in the industry. This would require big waves of dependency updates, where such updates sometimes will be impossible if only a single (transitive) dependency has not catched up, including major names such as Spring, Hibernate or Mockito. From experience, such major updating waves are often complex and therefore avoided, which will hinder adoption of future JVM versions. This seems like a very high price to pay which could be easily avoided by only keeping a handful of skeleton classes.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">cc'ing security-dev as that is the mailing list to use for this JEP.<br>
<br>
This JEP is the first of several in a multi-release/multi-year effort. <br>
It's way too early to give any guess as to when the APIs will be <br>
removed. As the JEP says, future releases may degrade the SM APIs so <br>
that System.getSM returns always returns null or <br>
AccessController::doPriv just runs the action. This should mean that <br>
libraries that are compiling to older releases should continue to <br>
compile and run on those releases. When they run on some future release <br>
that degrades the implementation then it will be as if there is no SM.  <br>
So I would say the impact is little to none for libraries for the <br>
foreseeable future.<br>
<br>
-Alan<br>
<br>
<br>
On 13/06/2021 21:28, Rafael Winterhalter wrote:<br>
> I am currently looking into how I should address JEP 411 in my library Byte<br>
> Buddy and I find it rather challenging. The problem I am facing is that I<br>
> know of several users who rely on the security manager in their Java 8/11<br>
> applications. I would like to continue to support those users' use cases as<br>
> long as I support Java versions that contain the security manager, which<br>
> will be for many years to come. At the same time, I would like to address<br>
> the announced removal of the API and make sure that Byte Buddy can work<br>
> without it prior to the deadline when the library in its current state<br>
> would no longer link.<br>
><br>
>  From my understanding of the intention of JEP 411, the API was supposed to<br>
> be stubbed – similar to Android’s stubbing of the API - rather than being<br>
> removed. However, with the announced deprecation for removal of<br>
> AccessController and SecurityManager, I understand that I would need to<br>
> fully remove the dispatching to work with future Java versions.<br>
><br>
> Furthermore, it is difficult to create a working facade for dispatching to<br>
> the security manager only if it is available. Methods like<br>
> AccessController.doPrivileged are caller sensitive and by adding a utility<br>
> to a library, this utility would leak to any potential user. It would<br>
> therefore require package-private dispatchers for any relevant package,<br>
> which would lead to a lot of copy-paste to retain backwards compatibility<br>
> (given that a library cannot assume to be run as a module).<br>
><br>
> Finally, removing the API would mean that Byte Buddy versions of the last<br>
> ten years would no longer link in future JDKs. For Byte Buddy where new<br>
> Java versions often require an update, that might not be a big issue but<br>
> many other libraries do support the API, I don’t feel it would be a rather<br>
> severe restriction and cause unnecessary breakage if API is removed, rather<br>
> than stubbed. I am thinking of libraries like Netty here which are rather<br>
> omnipresent and would suddenly no longer link, a concept that is unlikely<br>
> intuitive to a lot of developers.<br>
><br>
> Therefore, my question is: should SecurityManager, AccessController and the<br>
> Policy APIs really be deprecated for removal? Rather, I think that the APIs<br>
> should be deprecated, but be retained with stubbed implementations.<br>
> System.getSecurityMananger would then always return null.<br>
> System.setSecurityManager on the other hand could be deprecated for<br>
> removal. This way, existing code could continue to work as if the security<br>
> manager is not active, which already is the common scenario and would not<br>
> cause any disruption at the small price of keeping a handful of some<br>
> stubbed classes.<br>
><br>
> Thanks for advice on how this is intended to be handled by library<br>
> developers like me.<br>
> Best regards, Rafael<br>
<br>
</blockquote></div>