On 12.09.2016 17:08, Mark Reinhold wrote:
Issue summary

   #ReflectiveAccessToNonExportedTypes --- Some kinds of framework
   libraries require reflective access to members of the non-exported
   types of other modules; examples include dependency injection (Guice),
   persistence (JPA), debugging tools, code-automation tools, and
   serialization (XStream).  In some cases the particular library to be
   used is not known until run time (e.g., Hibernate and EclipseLink both
   implement JPA).  This capability is also sometimes used to work around
   bugs in unchangeable code.  Access to non-exported packages can, at
   present, only be done via command-line flags, which is extremely
   awkward.  Provide an easier way for reflective code to access such
   non-exported types. [1]

   #AwkwardStrongEncapsulation --- A non-public element of an exported
   package can still be accessed via the `AccessibleObject::setAccessible`
   method of the core reflection API.  The only way to strongly
   encapsulate such an element is to move it to a non-exported package.
   This makes it awkward, at best, to encapsulate the internals of a
   package that defines a public API. [2]

I´d like to give some feedback on this. Our situation was this, that we finally managed to get the Groovy build running on JDK9 with the jigsaw version before this change here came live. The situation now is, that gradle broke and we are not even starting compilation anymore. Well, can happen with a change like this. But the issue at hand was about using setAccessible (without exporting private) to get access to a protected method in java.base. When this proposal mentioned non-public I was actually automatically thinking private, but of course there are at least two more visibility options to think of.

So I find another awkward point in #AwkwardStrongEncapsulation in that you have exported API and you have a protected method in it. You can write a class in your own module, that will overwrite or use that method given that it is in a subclass. But if I want to use setAccessible to invoke the method I cannot do that? This is awkward to me, because it degrades the former (and often misused) swiss-army-knife setAccessible to something that is even less capable than what I can do by subclassing - unless special action are taken. I can understand the idea for private methods or package private - but protected is for me always part of the API to program against and as such it makes not sense to me to prevent setAccessible accessing it here.

bye Jochen

Reply via email to