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

2017-01-07 Thread Rony G. Flatscher
Hi Peter, again, thank you very much! I have marked your idea/suggestion in order to be able to get back to it when I get free time on my hands to test and experiment with new alternatives. In this case it will be interesting to learn about its runtime effects for users who have long-running

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

2017-01-07 Thread Peter Levart
Hi Rony (sent privately to not bother the list with this stuff). Here's a modified ReturnTypesList that also keeps track of all the distinct methods that can be called: public class ReturnTypesList extends CopyOnWriteArrayList { private final Object lock = new Object();

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

2017-01-07 Thread Peter Levart
Hi Rony, Implementing explicit cast is easy in this scheme (the Java side): public static void cast(Object object, ReturnTypesList rtList, Class typeToCastTo) throws ClassCastException { typeToCastTo.cast(object); rtList.merge(typeToCastTo); } Peter On 01/07/2017 08:46 PM, Peter

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

2017-01-07 Thread Peter Levart
Hi Rony, As with all concurrent data structures that try to optimize something, you can get it wrong in the first try. Here's the corrected code: public class ReturnTypesList extends CopyOnWriteArrayList { private final Object lock = new Object(); public void merge(Class

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

2017-01-07 Thread Peter Levart
On 01/07/2017 07:25 PM, Rony G. Flatscher wrote: Hi Peter, thank you again for your effort, I really appreciate it! However, as you note at the end yourself, the problem is that any Java object could be used concurrently in different usages of the Java bridge, so saving the last return

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

2017-01-07 Thread Rony G. Flatscher
Hi Peter, thank you again for your effort, I really appreciate it! However, as you note at the end yourself, the problem is that any Java object could be used concurrently in different usages of the Java bridge, so saving the last return type with the returned object is not feasible. E.g.

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

2017-01-07 Thread Peter Levart
Hi Rony, On 01/07/2017 03:53 PM, Rony G. Flatscher wrote: Hi Peter, thank you very much for your efforts! However, in this context there is a problem at hand, that there is no information available what Java method returned what object and what cast was carried out, if any. To understand

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

2017-01-07 Thread Rony G. Flatscher
Forgot to supply a reflective version for my sample classes, so for completeness here the reflective version E: class E { public static void main (String args[]) throws Exception { System.out.println("E: java.version="+System.getProperty("java.version"));

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

2017-01-07 Thread Rony G. Flatscher
Hi Peter, thank you very much for your efforts! However, in this context there is a problem at hand, that there is no information available what Java method returned what object and what cast was carried out, if any. To understand this, maybe I should give a little bit more information about

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

2017-01-07 Thread 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,

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

2017-01-06 Thread Peter Levart
Hi Rony, On 01/06/2017 02:28 PM, Rony G. Flatscher wrote: >The j.l.r.Method object on which you call invoke() should not be obtained by inspecting the >methods of the implementation class given by getDefaultToolkit().getClass(). Implementation >classes (i.e. classes in non-exported packages)

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

2017-01-06 Thread Michael Rasmussen
> 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

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

2017-01-06 Thread Rony G. Flatscher
On 05.01.2017 23:31, Alex Buckley wrote: > On 1/5/2017 1:16 PM, Rony G. Flatscher wrote: >> The rule for using the Java bridge for the Rexx programmers has always been >> very simple: you are >> only allowed to use public Java classes, public Java fields and public Java >> methods as these are

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

2017-01-06 Thread Alan Bateman
On 06/01/2017 12:26, Rony G. Flatscher wrote: Alan, thank you for your pointer. The code shown in [1] currently needs to access Java 9 features (to test whether the module is exported), which might not be a possibility for Java libraries that have a baseline like Java 1.4 (the GA version of

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

2017-01-06 Thread Michael Rasmussen
On 6 January 2017 at 10:24, Alan Bateman wrote: > There have been a couple of threads here (going back to 2015) on this > topic. Peter included a method [1] in one threads to walk the superclasses > and directly implemented interface of each class to find the accessible

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

2017-01-06 Thread Rony G. Flatscher
Alan, thank you for your pointer. The code shown in [1] currently needs to access Java 9 features (to test whether the module is exported), which might not be a possibility for Java libraries that have a baseline like Java 1.4 (the GA version of the Java bridge is at that level) or 1.6 (the

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

2017-01-06 Thread Alan Bateman
On 05/01/2017 20:07, Phil Race wrote: Sort of .. it depends whether you could use getDeclaredMethod instead. One question I have is, how would you update the code if you were given the instance "foo", and need to programmatically work out what is the correct super-type of Foo that exports the

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

2017-01-05 Thread Alex Buckley
On 1/5/2017 1:16 PM, Rony G. Flatscher wrote: The rule for using the Java bridge for the Rexx programmers has always been very simple: you are only allowed to use public Java classes, public Java fields and public Java methods as these are guaranteed to be available to everyone at all times.

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

2017-01-05 Thread Jochen Theodorou
On 05.01.2017 21:07, Phil Race wrote: Sort of .. it depends whether you could use getDeclaredMethod instead. One question I have is, how would you update the code if you were given the instance "foo", and need to programmatically work out what is the correct super-type of Foo that exports the

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

2017-01-05 Thread Rony G. Flatscher
; - Mail original - >> De: "Rony G. Flatscher" <rony.flatsc...@wu.ac.at> >> À: jdk9-...@openjdk.java.net >> Envoyé: Jeudi 5 Janvier 2017 20:03:02 >> Objet: Re: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() >> reflectively cause

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

2017-01-05 Thread Rony G. Flatscher
has to be >> declared public *and* the package has to be exported. >> >> cheers, >> Rémi >> >> - Mail original - >>> De: "Phil Race" <philip.r...@oracle.com> >>> À: "Alex Buckley" <alex.buck...@oracle.com>, jigsa

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

2017-01-05 Thread Phil Race
t; <alex.buck...@oracle.com>, jigsaw-dev@openjdk.java.net, "Rony G. Flatscher" <rony.flatsc...@wu.ac.at> Envoyé: Jeudi 5 Janvier 2017 20:45:56 Objet: Re: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException ah yes .. I can s

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

2017-01-05 Thread Phil Race
t; <alex.buck...@oracle.com>, jigsaw-dev@openjdk.java.net, "Rony G. Flatscher" <rony.flatsc...@wu.ac.at> Envoyé: Jeudi 5 Janvier 2017 20:45:56 Objet: Re: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException ah yes .. I can s

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

2017-01-05 Thread Remi Forax
er 2017 20:45:56 > Objet: Re: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() > reflectively causes InaccessibleObjectException > ah yes .. I can see how one might code that way. > I don't know how common a problem this is, but > such code will need to be updated. > > &

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

2017-01-05 Thread Phil Race
Just for clarification .. I was also testing what happened with getDeclaredMethod (which is not delcared on that X11 sub-class) .. and that caused the NoSuchMethodException I pasted in my previous email. With "getMethod" I see what Rony reports. ~/jdk9b142/bin/java TK8 class

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

2017-01-05 Thread Phil Race
ah yes .. I can see how one might code that way. I don't know how common a problem this is, but such code will need to be updated. import java.awt.Toolkit; public class TK8 { public static void main(String args[]) throws Exception { Toolkit tk = Toolkit.getDefaultToolkit();

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

2017-01-05 Thread Alex Buckley
Rony mentioned "the returned Toolkit is of type sun.awt.X11.XToolkit" which suggests that he is calling getClass() on the result of getDefaultToolkit(), and then reflecting further on that Class object and its Methods. As has been discussed previously on jigsaw-dev, this won't work for

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

2017-01-05 Thread Phil Race
This should be discussed on jigsaw-dev. But can you share your code ? - since the following works for me : import java.awt.Toolkit; public class TK { public static void main(String args[]) throws Exception { Toolkit tk = Toolkit.getDefaultToolkit(); Class tkc =