Proxy classes and reflection (IllegalAccessException)

Alan Bateman Alan.Bateman at oracle.com
Thu Apr 7 20:47:26 UTC 2016


On 07/04/2016 21:22, David M. Lloyd wrote:
> Having the proxy class be public in most circumstances is a 
> 15-plus-year-old contract. 
Proxy classes were specified to be public up to Java SE 7. There was a 
significant update in Java SE 8 to specify that the proxy classes be 
non-public when any of the interfaces is not public. The draft changes 
in JDK 9 is further evolution to specify the proxy class accessibility 
based on the least accessible interface.


> :
>
> The first problem is that a magic dynamic module is created for proxy 
> classes.  This is a bit of a punt because of the natural 
> dissonance/chaos that arises from decoupling the module from the class 
> loader; however there's possibly a better way to mitigate this: let 
> the layer decide how to place the proxy class into a *real* module the 
> same way that in the past, the proxy class was placed into the real 
> class loader as a normal (usually public) class.
There are cases where the proxy class will be generated in the same 
package/module as the proxy interface. Hopefully the "Package and Module 
Membership of Proxy Class" section in the javadoc is clear on all the cases.

>
>
> The second problem is that the requirement for adding read edges all 
> over the place for reflection is unreasonable (and has already been 
> recognized as such by the EG). 
This is #ReflectionWithoutReadability on the issues list and has already 
been resolved [1].

-Alan

[1] 
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-March/000248.html




More information about the jigsaw-dev mailing list