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