Suggestion: allow accessible reflection on protected methods of exported types.
blackdrag at gmx.org
Thu Dec 29 16:39:38 UTC 2016
On 29.12.2016 17:24, Rafael Winterhalter wrote:
> Hello everybody,
> I did another round of testing a recent build of Java 9 with some
> applications and framework that I work with or maintain. I ran into an
> issue that I consider rather severe and I want to make a suggestion on how
> to potentially solve this problem.
> Some libraries entertain utilities that access protected methods of
> exported types to enhance their functionality without requiring a user to
> provide a specific subclass of such an instance but to allow them to use
> “their“ implementation. To access these protected methods, reflection is
> used in combination with AccessibleObject::setAccessible.
> For example, this approach is used by code generation libraries to invoke
> the ClassLoader::defineClass method which allows the injection of proxy
> types into the class loader of the proxied class. With the new constraints
> enforced by Jigsaw, attempting to make ClassLoader::defineClass accessible
> fails with:
while I am on your side and while I did bring this up myself in the
past, let me play the devil´s advocate here and ask: Why can´t this be
solved by subclassing? For example you can create a new class loader
that makes defineClass public and use that class loader as a child of
the class loader, which defines the class you want to proxy. Basically
this targets at the question of if these libraries are using the API
wrong, or if the API is wrong and if an alternative has to be created..
which does already exist with Unsafe.
More information about the jigsaw-dev