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

Rafael Winterhalter rafael.wth at gmail.com
Thu Dec 29 17:24:47 UTC 2016


Hei Jochen, thank you for your feedback. I must have missed your posting, I
regularly fail to follow up on the things discussed on the mailing list and
its not easy to seatch for topics, sorry for that.

In Byte Buddy, I created an option to use subclassing by creating dedicated
class loaders for proxy classes. There is however a row of disadvantages:

1. Class loaders are not cheap objects, they require some memory and the
performance cost of creating dedicated class loaders is significant. I have
benchmarked this, as well and it costs you about three times the time to
create such "wrapper class loaders" rather than injecting.

2. It is close to impossible to define a good life-cycle for classes loaded
by such wrapper class loaders. You need to keep a reference to the proxy
class to prohibit its collection which in turn keeps a reference to the
original class loader making it uncollectable. Using soft or weak
references is less then ideal, too and the only option would be to use
ephemerons which are not supported by Java. With injection, it is as easy
as looking up a previously created class from the proxied class's class
loader which dies and lives with this class loader.

3. Java packages define their identity by name and class loader at runtime.
Many developers use anonymous classes or nested classes which are
package-private and cannot be subclassed by creating a new class loader but
which must live in the same class loader.

Those are the main issues that lead us to strongly prefer injection,
especially in a testing library like Mockito and there are some more
complications that we would like to avoid.

I am however especially concerned about upgrading. Esepcially with mature
and wide-spread libraries like Mockito or Hibernate, even minor changes can
cause really big, hard-to-debug issues for our users. Switching from
injection to subclassing would be much more than a minor change. The JVM
developers surely know this, otherwise they would not keep classes like
Stack around or fix quirks in classes like ByteBuffer. Too much code was
written on top of these classes and their expected inner working. If we
were however forced to change our APIs that drastically, I think the real
consequences would be much more drastic than the mentioned changes. At the
moment, as a library author, I do however feel like there are few options
to avoid this.

Best regards, Rafael

2016-12-29 17:39 GMT+01:00 Jochen Theodorou <blackdrag at gmx.org>:

> 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.
>
> by Jochen
>
>


More information about the jigsaw-dev mailing list