[armedbear-devel] Question about calling Java
nitralime
nitralime at googlemail.com
Wed Feb 3 17:46:12 UTC 2010
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.
>
>
More information about the armedbear-devel
mailing list