[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 
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");
> 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"
> 	  (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