Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException

Rony G. Flatscher Rony.Flatscher at
Sat Jan 7 13:58:27 UTC 2017

On 06.01.2017 17:03, Michael Rasmussen wrote:
>> To turn back to the root cause: using reflection a public class from java.desktop is loaded, one of
>> its public static methods gets employed and returns an object of the type of that public
>> java.desktop class. Under the covers, however, an object gets returned which got instantiated by
>> that java.desktop class from a class that resides in a module that is open to java.desktop, but
>> closed to others.
>> This action is not under control of the reflective code, it is the sole responsibility of the
>> accessible public class' public method. Applying reflectiveness on that object, like it has been
>> possible for many Java versions and years in the past, all of a sudden breaks in this case with an
>> exception, that pre-Java-9 code could never have taken into account. The code does nothing unusual
>> and respects the publicness of classes and its public members.
>> So the current implementation of the module access rules to public (!) methods of the returned
>> object/in place of an accessible public class/ may break existing, proven, legitimate, reflective code.
> Pre-java-9 code must still take accessibility into account, as the
> method might return a non-public implementation of the public API.
> Granted, previously it was easier to bypass this using setAccessible.
> Simple example of such a scenario:
This is a (nice, but totally) different example from the presented use-case, which pattern may be
applied in many deployed Java applications that would unexpectedly break with the current


More information about the jigsaw-dev mailing list