[armedbear-devel] Question about calling Java
Usually, I can find a way to translate given Java code into the ABCL equivalent. Sometimes it takes quite a while to figure the correct syntax which I attribute to the organically evolved nature of our Java integration, but I have never found something ultimately unexpressable. Until now, although I think this has to do with me trying to debug ABCL internals with the ABCL REPL, but I want to document it. Have I missed some way of making this call? The code: SimpleString h = new SimpleString("FOO"); Pathname.LOGICAL_PATHNAME_TRANSLATIONS.get(h)); LOGICAL_PATHNAME_TRANSLATIONS is a EqualHashTable object whose signature of get() is LispObject get(LispObject key) This fails (jcall "get" (jfield "org.armedbear.lisp.Pathname" "LOGICAL_PATHNAME_TRANSLATIONS) (jnew "org.armedbear.lisp.SimpleString" "FOO")) with the error The value "org.armedbear.lisp.SimpleString" is not of type JAVA-OBJECT Diving into the code shows that the Java.translateMethodArguments() call is always going to translate the SimpleString argument into a instance of java.lang.String as this is what SimpleString.javaInstance() returns. Is there any way to tell JCALL not to perform such translation on its arguments? JCALL-RAW doesn't convert its return value, but maybe we need a JCALL-NAKED that doesn't translate its arguments? I suspect that we don't need JCALL-NAKED for anyone not using Java objects that are descendents of org.armedbear.lisp.LispObject but I'm not exactly sure how to prove this claim. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 22/10 5:50 PM, Mark Evenson wrote: […]
arguments? JCALL-RAW doesn't convert its return value, but maybe we need […] This should read:
"JCALL-RAW only converts its return value" -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
2010/2/2 Mark Evenson <evenson@panix.com>:
returns. Is there any way to tell JCALL not to perform such translation on its arguments? JCALL-RAW doesn't convert its return value, but maybe we need a JCALL-NAKED that doesn't translate its arguments? I suspect
Maybe we need an argument converter function that can decide on a per-argument basis whether an argument needs conversion or not? You can then do jcall-raw/jcall-naked invocations as macros on top of it.
On Tue, Feb 2, 2010 at 6:02 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
2010/2/2 Mark Evenson <evenson@panix.com>:
returns. Is there any way to tell JCALL not to perform such translation on its arguments? JCALL-RAW doesn't convert its return value, but maybe we need a JCALL-NAKED that doesn't translate its arguments? I suspect
Maybe we need an argument converter function that can decide on a per-argument basis whether an argument needs conversion or not? You can then do jcall-raw/jcall-naked invocations as macros on top of it.
We just need a way to wrap a LispObject in a JavaObject, say, (jraw foo) == new JavaObject(foo). Then plain jcall/jcall-raw will work as intended. I also think that this problem is partly related to another, old problem of ABCL, i.e. that javaInstance(Class) does not have consistently the semantics of returning an instance of the class passed as argument. If Mark had used (jcall (jmethod ...) ...) ABCL would have had the argument type information available and would have used that to call javaInstance(Class). However, that wouldn't have worked anyway because SimpleString.javaInstance(Class) does not take the class into consideration at all. Imho it should do something like: if(clazz.isAssignableFrom(String.class)) { return javaInstance(); } else { return super.javaInstance(clazz); } where super.javaInstance(clazz) is if(clazz.isAssignableFrom(getClass())) { return this; } else { return error(...); } I believe that if these semantics were consistently given to all the javaInstance(Class) methods some parts of ABCL would become a little saner and it would be generally easier to turn Lisp objects into Java objects. We could also generify javaInstance(Class) to make things like String s = foo.javaInstance(String.class) work. Just my 2 cents. Alessio
IMHO, the ablity of using Java libraries easily should be an integral part of every language targeting JVM! I find it very unfortunate that the Java integration of ABCL is practically (i.e. out of the box) absent. On 02/02/2010 05:50 PM, Mark Evenson wrote:
Usually, I can find a way to translate given Java code into the ABCL equivalent. Sometimes it takes quite a while to figure the correct syntax which I attribute to the organically evolved nature of our Java integration, but I have never found something ultimately unexpressable. Until now, although I think this has to do with me trying to debug ABCL internals with the ABCL REPL, but I want to document it. Have I missed some way of making this call?
The code:
SimpleString h = new SimpleString("FOO"); Pathname.LOGICAL_PATHNAME_TRANSLATIONS.get(h));
LOGICAL_PATHNAME_TRANSLATIONS is a EqualHashTable object whose signature of get() is
LispObject get(LispObject key)
This fails
(jcall "get" (jfield "org.armedbear.lisp.Pathname" "LOGICAL_PATHNAME_TRANSLATIONS) (jnew "org.armedbear.lisp.SimpleString" "FOO"))
with the error
The value "org.armedbear.lisp.SimpleString" is not of type JAVA-OBJECT
Diving into the code shows that the Java.translateMethodArguments() call is always going to translate the SimpleString argument into a instance of java.lang.String as this is what SimpleString.javaInstance() returns. Is there any way to tell JCALL not to perform such translation on its arguments? JCALL-RAW doesn't convert its return value, but maybe we need a JCALL-NAKED that doesn't translate its arguments? I suspect that we don't need JCALL-NAKED for anyone not using Java objects that are descendents of org.armedbear.lisp.LispObject but I'm not exactly sure how to prove this claim.
On Wed, Feb 3, 2010 at 6:46 PM, nitralime <nitralime@googlemail.com> wrote:
IMHO, the ablity of using Java libraries easily should be an integral part of every language targeting JVM! I find it very unfortunate that the Java integration of ABCL is practically (i.e. out of the box) absent.
Why do you say that? ABCL's Java FFI is somewhat verbose, but apart from this limitation that Mark found, and maybe some things that could be polished and made more uniform, you can do anything you want.
On 02/02/2010 05:50 PM, Mark Evenson wrote:
Usually, I can find a way to translate given Java code into the ABCL equivalent. Sometimes it takes quite a while to figure the correct syntax which I attribute to the organically evolved nature of our Java integration, but I have never found something ultimately unexpressable. Until now, although I think this has to do with me trying to debug ABCL internals with the ABCL REPL, but I want to document it. Have I missed some way of making this call?
The code:
SimpleString h = new SimpleString("FOO"); Pathname.LOGICAL_PATHNAME_TRANSLATIONS.get(h));
LOGICAL_PATHNAME_TRANSLATIONS is a EqualHashTable object whose signature of get() is
LispObject get(LispObject key)
This fails
(jcall "get" (jfield "org.armedbear.lisp.Pathname" "LOGICAL_PATHNAME_TRANSLATIONS) (jnew "org.armedbear.lisp.SimpleString" "FOO"))
with the error
The value "org.armedbear.lisp.SimpleString" is not of type JAVA-OBJECT
Diving into the code shows that the Java.translateMethodArguments() call is always going to translate the SimpleString argument into a instance of java.lang.String as this is what SimpleString.javaInstance() returns. Is there any way to tell JCALL not to perform such translation on its arguments? JCALL-RAW doesn't convert its return value, but maybe we need a JCALL-NAKED that doesn't translate its arguments? I suspect that we don't need JCALL-NAKED for anyone not using Java objects that are descendents of org.armedbear.lisp.LispObject but I'm not exactly sure how to prove this claim.
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 2/3/10 8:00 PM, Alessio Stalla wrote:
On Wed, Feb 3, 2010 at 6:46 PM, nitralime<nitralime@googlemail.com> wrote:
IMHO, the ablity of using Java libraries easily should be an integral part of every language targeting JVM! I find it very unfortunate that the Java integration of ABCL is practically (i.e. out of the box) absent.
Why do you say that? ABCL's Java FFI is somewhat verbose, but apart from this limitation that Mark found, and maybe some things that could be polished and made more uniform, you can do anything you want.
We would probably be using SBCL if we didn't want integration with the JVM… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 02/03/2010 08:05 PM, Mark Evenson wrote:
On 2/3/10 8:00 PM, Alessio Stalla wrote:
On Wed, Feb 3, 2010 at 6:46 PM, nitralime<nitralime@googlemail.com> wrote:
IMHO, the ablity of using Java libraries easily should be an integral part of every language targeting JVM! I find it very unfortunate that the Java integration of ABCL is practically (i.e. out of the box) absent.
Why do you say that? ABCL's Java FFI is somewhat verbose, but apart from this limitation that Mark found, and maybe some things that could be polished and made more uniform, you can do anything you want.
We would probably be using SBCL if we didn't want integration with the JVM…
My description of the situation was intentionally provocative :-( I just wanted to draw your attention to the fact that the current JVM integration could be more user friendly than what it is now! A more systematic tutorial would also be very nice for inexperienced users like me :-)
On 4 February 2010 13:24, Nitralime <nitralime@googlemail.com> wrote:
My description of the situation was intentionally provocative :-( I just wanted to draw your attention to the fact that the current JVM integration could be more user friendly than what it is now! A more systematic tutorial would also be very nice for inexperienced users like me :-)
Well, you're then obviously in a unique position to write such a tutorial, because you'll notice things that are hard to find in other documentation, and you'll notice where the APIs are lacking in usability. :) More to the point, you could write a draft/skeleton of such a tutorial, and then recruit our help for things that you can't find or understand. Sure, that was a common open-source-project-reply ("if you want improvements, do them yourself"), but I think it would be a very valuable and highly appreciated contribution. I wrote many of the current examples we have, and if those are hard to follow, I'm not surprised - I absolutely suck at tutorials and documentation-for-novices. That's why it would be great to have contributions in that area.
On 02/04/2010 01:48 PM, Ville Voutilainen wrote:
On 4 February 2010 13:24, Nitralime<nitralime@googlemail.com> wrote:
My description of the situation was intentionally provocative :-( I just wanted to draw your attention to the fact that the current JVM integration could be more user friendly than what it is now! A more systematic tutorial would also be very nice for inexperienced users like me :-)
Well, you're then obviously in a unique position to write such a tutorial, because you'll notice things that are hard to find in other documentation, and you'll notice where the APIs are lacking in usability. :)
More to the point, you could write a draft/skeleton of such a tutorial, and then recruit our help for things that you can't find or understand.
Sure, that was a common open-source-project-reply ("if you want improvements, do them yourself"), but I think it would be a very valuable and highly appreciated contribution. I wrote many of the current examples we have, and if those are hard to follow, I'm not surprised - I absolutely suck at tutorials and documentation-for-novices. That's why it would be great to have contributions in that area.
I appreciate the work of (voluntary) developers very much. It is clear that they have other priorities than writing documentations or tutorials! On the other hand, making the result of their efforts accessible to a wider audience is very important for its popularity. You can be assured that if I can contribute anything to this project I will do it!!
Hi Nitralime,
I wrote many of the current examples we have, and if those are hard to follow, I'm not surprised - I absolutely suck at tutorials and documentation-for-novices. That's why it would be great to have contributions in that area.
I appreciate the work of (voluntary) developers very much. It is clear that they have other priorities than writing documentations or tutorials! On the other hand, making the result of their efforts accessible to a wider audience is very important for its popularity.
You can be assured that if I can contribute anything to this project I will do it!!
Just last monday, I was talking to a friend of mine about the state of our documentation regarding Java integration. Just as the other developers, I have to agree it's rather lacking. (However, some people seem to be able to work with it, it surely would help our growth if the docs were better.) We kind of agreed there needs to be basic documentation (at first) in the form of small examples which show "how to". So, I'd like to take you up on your offer of helping us out: If you can help us write those examples, it would be really great! I'm thinking of a "Java integration FAQ" thing or "Doing ABCL Java integration by example". So, we need to identify the things people would want to see answered first when trying to use ABCL. If you ask me, this is where you would come in. Could you list a number of things you want to do with ABCL, but can't because you don't know how? Bye, Erik.
I've had the following challenges (for the first one I have a makeshift solution): - Implementing a servlet for/in ABCL - Streams, Iterators: How can these best be wrapped in ABCL? Greetings, Axel On Feb 4, 2010, at 18:19 , Erik Huelsmann wrote:
Hi Nitralime,
I wrote many of the current examples we have, and if those are hard to follow, I'm not surprised - I absolutely suck at tutorials and documentation-for-novices. That's why it would be great to have contributions in that area.
I appreciate the work of (voluntary) developers very much. It is clear that they have other priorities than writing documentations or tutorials! On the other hand, making the result of their efforts accessible to a wider audience is very important for its popularity.
You can be assured that if I can contribute anything to this project I will do it!!
Just last monday, I was talking to a friend of mine about the state of our documentation regarding Java integration. Just as the other developers, I have to agree it's rather lacking. (However, some people seem to be able to work with it, it surely would help our growth if the docs were better.)
We kind of agreed there needs to be basic documentation (at first) in the form of small examples which show "how to". So, I'd like to take you up on your offer of helping us out: If you can help us write those examples, it would be really great!
I'm thinking of a "Java integration FAQ" thing or "Doing ABCL Java integration by example". So, we need to identify the things people would want to see answered first when trying to use ABCL. If you ask me, this is where you would come in. Could you list a number of things you want to do with ABCL, but can't because you don't know how?
Bye,
Erik.
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
-- Axel.Rauschmayer@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
Not sure if we have this linked but generally this was the original spec http://www.franz.com/support/documentation/current/doc/jlinker.htm When using that doc, generally the symbols with "jlinker" in their name are not needed in ABCL (they are used to manage a connection for operation and ABCL already has a jvm present) Also some things like "discard-in-java" are not needed eigther. Some things like "jcons" are legacy interface and usually will say things like: "This is a deprecated (maintained for now for backward compatibility) name of the function *jconstructor*<http://www.franz.com/support/documentation/current/doc/operators/jlinker/jconstructor.htm>. Please use *jconstructor*<http://www.franz.com/support/documentation/current/doc/operators/jlinker/jconstructor.htm>instead of *jcons*. See *jconstructor*<http://www.franz.com/support/documentation/current/doc/operators/jlinker/jconstructor.htm>for details. " There maybe other minor detail differences. If there is something one just can not live without like: def-java-* function they can probly be incorperated.
On Thu, Feb 4, 2010 at 12:24 PM, Nitralime <nitralime@googlemail.com> wrote:
On 02/03/2010 08:05 PM, Mark Evenson wrote:
On 2/3/10 8:00 PM, Alessio Stalla wrote:
On Wed, Feb 3, 2010 at 6:46 PM, nitralime<nitralime@googlemail.com> wrote:
IMHO, the ablity of using Java libraries easily should be an integral part of every language targeting JVM! I find it very unfortunate that the Java integration of ABCL is practically (i.e. out of the box) absent.
Why do you say that? ABCL's Java FFI is somewhat verbose, but apart from this limitation that Mark found, and maybe some things that could be polished and made more uniform, you can do anything you want.
We would probably be using SBCL if we didn't want integration with the JVM…
My description of the situation was intentionally provocative :-( I just wanted to draw your attention to the fact that the current JVM integration could be more user friendly than what it is now!
Do you have ideas on how to make it more user-friendly?
A more systematic tutorial would also be very nice for inexperienced users like me :-)
I agree, something like "how to use <insert java library here> with abcl" would be useful as a starting point for new users. Would you volunteer to write it? ;) More seriously, like Ville said, it would be nice if you identified what is hard for you and what is lacking in documentation, and write a report about it; someone else, or yourself when you'll have more experience, will eventually be able to use that information to make our documentation better. Alessio
Quick comment: The latest incarnation of the Java FFI API allows one to use strings whenever a class object or a method object is required: (jnew "my.package.MyClass" arg) for new my.package.MyClass(arg) (jcall "methodName" obj arg) for obj.methodName(arg) This is certainly good enough for me. I don't know how efficient the produced code is, but this is currently not an issue for me. On Feb 4, 2010, at 14:50 , Alessio Stalla wrote:
On Thu, Feb 4, 2010 at 12:24 PM, Nitralime <nitralime@googlemail.com> wrote:
On 02/03/2010 08:05 PM, Mark Evenson wrote:
On 2/3/10 8:00 PM, Alessio Stalla wrote:
On Wed, Feb 3, 2010 at 6:46 PM, nitralime<nitralime@googlemail.com> wrote:
IMHO, the ablity of using Java libraries easily should be an integral part of every language targeting JVM! I find it very unfortunate that the Java integration of ABCL is practically (i.e. out of the box) absent.
Why do you say that? ABCL's Java FFI is somewhat verbose, but apart from this limitation that Mark found, and maybe some things that could be polished and made more uniform, you can do anything you want.
We would probably be using SBCL if we didn't want integration with the JVM…
My description of the situation was intentionally provocative :-( I just wanted to draw your attention to the fact that the current JVM integration could be more user friendly than what it is now!
Do you have ideas on how to make it more user-friendly?
A more systematic tutorial would also be very nice for inexperienced users like me :-)
I agree, something like "how to use <insert java library here> with abcl" would be useful as a starting point for new users. Would you volunteer to write it? ;) More seriously, like Ville said, it would be nice if you identified what is hard for you and what is lacking in documentation, and write a report about it; someone else, or yourself when you'll have more experience, will eventually be able to use that information to make our documentation better.
Alessio
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
-- Axel.Rauschmayer@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
On 4 February 2010 16:39, Axel Rauschmayer <axel@rauschma.de> wrote:
Quick comment: The latest incarnation of the Java FFI API allows one to use strings whenever a class object or a method object is required: (jnew "my.package.MyClass" arg) for new my.package.MyClass(arg) (jcall "methodName" obj arg) for obj.methodName(arg)
Does it allow both the "old" way and the stringified way? If so, is there a patch somewhere that we can integrate?
On Thu, Feb 4, 2010 at 3:49 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 4 February 2010 16:39, Axel Rauschmayer <axel@rauschma.de> wrote:
Quick comment: The latest incarnation of the Java FFI API allows one to use strings whenever a class object or a method object is required: (jnew "my.package.MyClass" arg) for new my.package.MyClass(arg) (jcall "methodName" obj arg) for obj.methodName(arg)
Does it allow both the "old" way and the stringified way?
Yes, it does. The stringified way is obviously slower, because it looks up the method at runtime.
If so, is there a patch somewhere that we can integrate?
It's already on trunk ;) Ale
On Thu, Feb 4, 2010 at 7:19 AM, Alessio Stalla <alessiostalla@gmail.com>wrote:
On Thu, Feb 4, 2010 at 3:49 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 4 February 2010 16:39, Axel Rauschmayer <axel@rauschma.de> wrote:
Quick comment: The latest incarnation of the Java FFI API allows one to use strings whenever a class object or a method object is required: (jnew "my.package.MyClass" arg) for new my.package.MyClass(arg) (jcall "methodName" obj arg) for obj.methodName(arg)
Does it allow both the "old" way and the stringified way?
Yes, it does. The stringified way is obviously slower, because it looks up the method at runtime.
So you are saying in the current interpreted mode it has to resolve the stringified method each time? So it would be fastest to: (setq *myjmethod* (jmethod "mypackage.AndClass" "methodName" (jclass "argType1") )) Then use (jcall *myjmethod* obj arg). Is the most effecient? instead of (jcall (jmethod "mypackage.AndClass" "methodName" (jclass "argType1") ) obj arg) In the future, (JLinker says in their future to so no hurry) that these forms will eventualy be bytecode. And ABCL will probably beat Allegro to it! Since we can use Hickey's methodolgy he used in clojure for finality of the bytecode methods. That the methods themselves wont ever need to use a java.lang.Method.invoke anymore unless the user left it too ambiguous.
On Thu, Feb 4, 2010 at 4:34 PM, dmiles@users.sourceforge.net <logicmoo@gmail.com> wrote:
On Thu, Feb 4, 2010 at 7:19 AM, Alessio Stalla <alessiostalla@gmail.com> wrote:
On Thu, Feb 4, 2010 at 3:49 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 4 February 2010 16:39, Axel Rauschmayer <axel@rauschma.de> wrote:
Quick comment: The latest incarnation of the Java FFI API allows one to use strings whenever a class object or a method object is required: (jnew "my.package.MyClass" arg) for new my.package.MyClass(arg) (jcall "methodName" obj arg) for obj.methodName(arg)
Does it allow both the "old" way and the stringified way?
Yes, it does. The stringified way is obviously slower, because it looks up the method at runtime.
So you are saying in the current interpreted mode it has to resolve the stringified method each time?
So it would be fastest to:
(setq *myjmethod* (jmethod "mypackage.AndClass" "methodName" (jclass "argType1") ))
Then use (jcall *myjmethod* obj arg). Is the most effecient?
instead of
(jcall (jmethod "mypackage.AndClass" "methodName" (jclass "argType1") ) obj arg)
No, those two are equally efficient because the compiler caches the method automatically in the second case. What is slower is (jcall "methodName" obj arg) i.e. without a jmethod form. methodName will need to be resolved for every call, so it's not a wise choice in code where performance is important. OTOH, the string-based solution is more flexible; it works for any obj and arg provided that obj has a method "methodName" with a single parameter, whose type is compatible with the type of arg.
In the future, (JLinker says in their future to so no hurry) that these forms will eventualy be bytecode.
(jcall (jmethod ...) ...) could definitely be translated to invokevirtual bytecode when all the arguments to jmethod are known at compile time. Same for (jnew (jconstructor ...) ...).
And ABCL will probably beat Allegro to it! Since we can use Hickey's methodolgy he used in clojure for finality of the bytecode methods.
Afaik, declaring methods to be final has little impact on performance with recent JVMs. HotSpot is able to infer if a method can or not be overridden and perform the appropriate optimizations. If later on a class is dynamically loaded that overrides an optimized method, HotSpot will "unoptimize" it. Alessio
That the methods themselves wont ever need to use a java.lang.Method.invoke anymore unless the user left it too ambiguous.
On Thu, Feb 4, 2010 at 7:52 AM, Alessio Stalla <alessiostalla@gmail.com>wrote:
Afaik, declaring methods to be final has little impact on performance with recent JVMs. HotSpot is able to infer if a method can or not be overridden and perform the appropriate optimizations. If later on a class is dynamically loaded that overrides an optimized method, HotSpot will "unoptimize" it.
What I meant by final wasn't about final modifiers on methods. What i refer to is when at compile time there is only one possible call site. for instance (jcall "toString" (jnew "java.lang.Integer" 1)) the emitted bytecode can invokevirtual "java.lang.Integer" "toString" ref0;
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Thu, Feb 4, 2010 at 6:39 AM, Axel Rauschmayer <axel@rauschma.de> wrote:
Quick comment: The latest incarnation of the Java FFI API allows one to use strings whenever a class object or a method object is required: (jnew "my.package.MyClass" arg) for new my.package.MyClass(arg)
Something nice is the (jnew "my.package.MyClass" arg) is going to be close to what one day will be emitted bytecode wise.
(jcall "methodName" obj arg) for obj.methodName(arg)
Then with this one as (jcall "pckgname.ClassOfArg" "methodName" obj arg) will be close to bytecoded form [I am not suggesting doing it right now since to *always* do it loses expressablity of code]
This is certainly good enough for me. I don't know how efficient the produced code is, but this is currently not an issue for me.
So do not be afraid of strings since that technically that is what will be emmited into classfile bytecode (later on) :) Note: if someone uses (jcall (jmethod "plgname.ClassOfArg" "methodName") obj arg) would could emit the invokevitual "plgname.ClassOfArg" "methodName" obj [args]; into bytecode
participants (8)
-
Alessio Stalla -
Axel Rauschmayer -
dmiles＠users.sourceforge.net -
Erik Huelsmann -
Mark Evenson -
Nitralime -
nitralime
-
Ville Voutilainen