Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException
Rony G. Flatscher
Rony.Flatscher at wu.ac.at
Thu Jan 5 21:27:34 UTC 2017
Just realized that the emails get divided now to jdk9-dev and jigsaw-dev (where most replies
occurred). Hence added a reply-to to jigsaw-dev.
On 05.01.2017 20:31, Remi Forax wrote:
> In your script,
> when you execute a.b().c(),
> you should not call getClass() on the result of a.b() but using the return type of b() like the compiler do.
> it will solve your issue.
if I knew which return type to use programmatically as Phil Race pointed out.
Taking your example and executing it in an interpreter causes two invocations:
whatever b() returned will be stored in the Map and the key (a string) is returned to Rexx.
In the next step this string is supplied to the Java bridge with the method c to execute, hence
(unlike the compiler) no context available on the Java bridge at the time of the next invocation
> ----- Mail original -----
>> De: "Rony G. Flatscher" <Rony.Flatscher at wu.ac.at>
>> À: jdk9-dev at openjdk.java.net
>> Envoyé: Jeudi 5 Janvier 2017 20:03:02
>> Objet: Re: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException
>> Experimenting with further scripts indicates that this is a systematic problem
>> whenever the official
>> APIs return members that are not made available to an unnamed module: e.g.
>> JavaFX some
>> "com.sun.javafx.collections.VetoableListDecorator" or in a "plain" awt/swing app
>> On 05.01.2017 19:42, Rony G. Flatscher wrote:
>>> Trying to run a program that gets the screen dimensions using
>>> java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively.
>>> On a 64-bit Ubuntu the returned Toolkit is of type sun.awt.X11.XToolkit.
>>> Reflectively invoking its
>>> method getScreenSize() causes the following exception to be thrown on 9-ea+134:
>>> java.lang.reflect.InaccessibleObjectException: unable to make member of class
>>> accessible: module java.desktop does not export sun.awt to unnamed module ...
>>> A little bit baffled as this is from a script that has been working flawlessly
>>> throughout more than
>>> a decade on various Java versions and which employs documented public methods
>>> only (the sun.awt
>>> object is returned by java.awt.Toolkit). Is this a known "legacy"problem :) that
>>> I could circumvent
>>> somehow or a bug that needs to be reported?
More information about the jigsaw-dev