Suggestion: allow accessible reflection on protected methods of exported types.

Rafael Winterhalter rafael.wth at
Mon Jan 2 18:36:17 UTC 2017

(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

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

More information about the jigsaw-dev mailing list