Question ad #AwkwardStrongEncapsulation (Re: Moving the changes in jake to jdk9/dev

[Alex Buckley]

On 12/11/2016 8:16 AM, Rony G. Flatscher wrote:
> On 23.11.2016 12:55, Alan Bateman wrote:
>> As people on this mailing list know, jake has the changes for #AwkwardStrongEncapsulation [1]
>> where setAccessible has been changed so it can't be used to break into non-public members/types in
>> exported packages of JDK modules. It was changed more than a year ago to fail when attempting to
>> use it to break into non-exported packages. Dialing it up further is a disruptive change that will
>> expose a lot of hacks and issues with existing code that is used to accessing non-public
>> fields/methods in JDK classes. It will take some libraries and tools a bit of time to digest this
>> change, even with the --add-opens command line option and Add-Opens manifest in application JAR
>> files to keep existing code going. I plan to send mail to jdk9-dev in advance of this integration
>> to create wider awareness of this change.
>>
>> -Alan
>>
>> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation
> Would #AwkwardStrongEncapsulation inhibit setAccessible to work on protected methods (in addition to
> private and package private members) as well?
>
> As subclasses are allowed to access protected members in their superclasses, setAccessible should
> work for protected methods in classes that are invoked for objects that are instances of their
> subclasses?

The ability of protected members to be accessed from outside their 
package means they are essentially public members for the purposes of 
inheritance and reflection. So, setAccessible should work for protected 
members of exported packages. I know what you mean about the receiver 
object being of the correct class, but that's outside the capability of 
setAccessible to check, so I don't believe it is checked.

Alex