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

[Rony G. Flatscher]

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.
Agreed.
> Simple example of such a scenario:
> https://gist.github.com/anonymous/2c87d8a88b3c1a449b54deab4ec3fe88
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
implementation.

---rony