AccessibleObject.setAccessible() backward compatibility

Tim Boudreau niftiness at
Fri Sep 11 18:05:36 UTC 2015

If the implementation of MethodHandle uses setAccessible() (I don't know
its internals), then this Java 0day would qualify:

which I picked apart here:


On Fri, Sep 11, 2015 at 1:44 PM, David M. Lloyd <david.lloyd at>

> On 09/11/2015 12:15 PM, Remi Forax wrote:
>> There are two changes to setAccessible that make migration to the module
>> universe hard.
>> The first one is that setAccessible() is now declared final which is a
>> binary incompatible change so it breaks Guava two projects of mine.
>> The second change is that now setAccessible() is now CallerSensitive and
>> throw an exception if the AccessibleObject is not visible from the caller
>> class.
>> While this change may improve the security, it's a backward incompatible
>> change is not strictly required to support modules it's more an enhancement
>> of the current security model and i don't think it's a good idea to mix it
>> with the introduction of the module support. More philosophically, every
>> libraries that propose an abstraction that hide underlying dirts provides
>> an escape hatch, the reflection API is one of such hatch of Java the
>> language allowing to bypass the typechecker and the security sandbox.
>> Trying to close the hatch will just make people to open holes in the nearby
>> wall with hacks that are less secure and that may even compromise the
>> integrity of the plateform.
> I'm not sure there are real-world cases where the additional accessibility
> rules are actually useful or improve security in any real way.  Maybe we
> need some sample use cases that we can pick apart?
> --
> - DML


More information about the jpms-spec-observers mailing list