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

Peter Levart peter.levart at
Mon Dec 12 21:42:24 UTC 2016

On 12/12/2016 08:56 PM, Alex Buckley wrote:
> 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] 
>> 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

That's right, currently setAccessible is allowed only within a module, 
for any members of any classes in unnamed module(s), for public members 
of public classes in exported packages of named module(s) and for any 
members of any classes of open packages. Here's the actual code used to 
check the ability to make a member setAccessible(true):

     void checkCanSetAccessible(Class<?> caller, Class<?> declaringClass) {
         Module callerModule = caller.getModule();
         Module declaringModule = declaringClass.getModule();

         if (callerModule == declaringModule) return;
         if (callerModule == Object.class.getModule()) return;
         if (!declaringModule.isNamed()) return;

         // package is open to caller
         String pn = packageName(declaringClass);
         if (declaringModule.isOpen(pn, callerModule))

         // package is exported to caller and class/member is public
         boolean isExported = declaringModule.isExported(pn, callerModule);
         boolean isClassPublic = 
         int modifiers;
         if (this instanceof Executable) {
             modifiers = ((Executable) this).getModifiers();
         } else {
             modifiers = ((Field) this).getModifiers();
         boolean isMemberPublic = Modifier.isPublic(modifiers);
         if (isExported && isClassPublic && isMemberPublic)

         // not accessible
         String msg = "Unable to make ";
         if (this instanceof Field)
             msg += "field ";
         msg += this + " accessible: " + declaringModule + " does not \"";
         if (isClassPublic && isMemberPublic)
             msg += "exports";
             msg += "opens";
         msg += " " + pn + "\" to " + callerModule;

This could be relaxed a bit for protected static fields/methods and for 
protected constructors, but can't be for instance members, because there 
is no target object to check against when setAccessible() is called...

Regards, Peter

More information about the jigsaw-dev mailing list