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

[David M. Lloyd]

On 12/29/2016 01:09 PM, Jochen Theodorou wrote:
> 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.

Here's an important point about adoption (these are my own observations, 
not the EG's or my employer's).  One of the effects of the way Java is 
produced and its historical entrenchment is that no matter what happens, 
adoption is more or less inevitable; every prediction of Java's death 
has proven to be false (which of course doesn't stop pundits from doing 
so anyway).  Even if a future Java was terrible by many objective 
measures, its adoption will probably be eventually inexorable.  It would 
take something highly extraordinary to change these basic truths.  This 
is just the nature of the Java ecosystem today.  Lack of adoption is a 
consequence that essentially nobody is worried about, and is really not 
a deterrent to any given proposed change.

But this just means that it is all the more critical that everyone that 
uses Java in their day to day work to take some degree of responsibility 
to ensure that every language and JDK specification change is reviewed 
for quality.  The JCP EC consists of many parties; it's my personal 
belief and hope that there will always be EC members (hopefully the 
majority of them in fact) that will listen to the practical concerns of 
the community.

It's not a perfect system but it's not terrible either!
-- 
- DML