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
