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
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();
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
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
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
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.
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
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"));
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
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,
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)
> 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
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
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
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
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
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
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.
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
; - 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
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
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
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
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.
>
>
&
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
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();
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
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 =
28 matches
Mail list logo