(Accidental enter hit during my last mail.) To give a short update on this:
I have now updated my code generation library Byte Buddy to fallback to sun.misc.Unsafe::defineClass for injecting types. I find this really unfortunate as I managed to avoid using Unsafe in Byte Buddy in five years and I am rather unhappy with this solution myself. Byte Buddy and cglib, another library I help maintain, amount to over 10 million yearly downloads and are consumed by a lot of infrastructure, also including the Spring framework which is not even accounted for in these download statistics due to its approach of copying the code without maintaining an explicit dependency. I am currently planing to also update cglib to using Unsafe rather than calling protected methods on ClassLoader as I do not see another way. I am really not trying to work against Jigsaw and I would prefer to not introduce a dependency to sun.misc.Unsafe to millions of Java projects. At the same time, I am under a bit of preasure myself to retain compatibility for my APIs what I cannot currently provide with the given constraints without any backdoors for library developers. This is especially true for cglib where even minor changes like the replacing of private field types often causes a lot of pain for adoperts. I understand that the latter problem is approached by Jigsaw and I would also prefer if this was something I did not have to deal with. At the same time, its about 20 years too late to change that. At the end of the day, there is a good reason that classes like Vector or Stack are still included in the Java packages, removing those classes would most likely cause a lot of trouble. I just really hope that it is considered that library maintainers face similar problems and just the many million downloads of tools that depend on such funcationality hopefully prove that we have created something useful that made Java a success and is worth being enabled with low-level APIs. I think it is in the platform's best interested if this happens in a structured manner where the access to such low-level is supported and therefore stable and controllable via infrastructure like a security manager. Otherwise, this will only trigger even uglier hacks compared to using the Unsafe class. I am still convinced that the capability of calling protected methods after setting setAccessible(true) would solve many of the current problems. I have talked to quite a few of other tools developers about this and we are all about anxious about these changes and how we can support Java 9 and Jigsaw. Many people now update their tools to inject helper classes into packages what is possible by Unsafe::defineClass. I think that given the current solution, Unsafe will eventually be used much more than currently. Other approaches set AccessibleObject:override to true using Unsafe::defineField. A third solution I have tried creates a subclass of some class where for example defineClass is invoked within a public method and where the "this" reference is replaced with a field value to invoke the protected method on some other instance of ClassLoader. The latter approach is my current option to avoid Unsafe but its also rather dirty. I really hope that some official API makes the cut. And allowing accessibility to protected methods via a security manger seems like a good option to me. In the end, I am still planing to remove the Unsafe fallback the first day a solution is offered. All the best, Rafael
