Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports

[Jochen Theodorou]

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