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

[Jochen Theodorou]

On 29.12.2016 18:24, Rafael Winterhalter wrote:
> 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.

don´t worry, my complaints have not been ignored, but did not change 
anything either.

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

agreed

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

A ClassValue is no ephemeron, but letting it keep a SoftReference to the 
proxy class may work. It means there will be situations in which the 
class will be recreated, but thanks to the SoftReference both classes 
and loaders should still be garbage collectable.

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

package-private is another story... I would be happy enough to have a 
generic solution for protected.

and 4.  if the  loader is defined by a module you will have fun with 
creating layers and export/read edges

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

the reply will most probably be about asking why these classes are not 
made public. They can be exported to only the framework module and all that.

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

been there and I agree. But it is unlikely that something like the 
implementation of strong encapsulation will be done without trouble for 
bigger projects. Will this lower adoption of Java9? Sure.

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

On the other hand... if you think it has to be done at some point, then 
why delay it? Of course the question of if it has to be done is 
questionable in itself, especially since the slim advantages of the 
module system turn into the negative, if weighted against "other 
solutions", the work you will have with it and the limitations it imposes.

bye Jochen