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

Rony G. Flatscher Rony.Flatscher at
Sun Dec 11 16:16:34 UTC 2016

On 23.11.2016 12:55, Alan Bateman wrote:
> We've been accumulating changes in the jake forest that are tied to JSR issues for the last few
> months. Some of the changes (such as #ClassLoaderNames) have already been pushed upstream to
> jdk9/dev but we've still sitting on a large patch.
> We would like to move the changes that we have in jake to jdk9/dev soon, early December if
> possible. One motivation is to get the changes and new APIs into JDK 9 main line so that they can
> be used and tested more widely. This should help reduce some of the confusion with having two
> builds too. Another motivation is that the merging is getting painful, esp. the langtools
> repository where we have regular conflicts with changes to javac pushed via jdk9/dev.
> To that end, I will start a code review soon that will be a snapshot of the changes in the jake
> forest. Once these changes are reviewed and in jdk9/dev then we will continue in the jake forest
> where appropriate - particularly in areas that are tied to JSR issues where we need to iterate and
> prototype, also in areas where we need to re-work some areas of the implementation.
> 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]
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


More information about the jigsaw-dev mailing list