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] > 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? ---rony
