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-OBJECTDiving 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.