(message (Hello 'Alan)
(you :wrote :on '(Wed, 2 May 2007 15:43:56 -0400))
(
AR> Say to store it in a java array of Object and retrieve it later?
i think easiest way would be to wrap it in a CONS. or if you prefer, in to
array -- you can create an array using jnew-array..
there is also java.lang.ref.Reference class, but it's weird..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")

Sample code would be good. I don't think that this works. All calls
go through jcall, jstatic etc, all of which seem to call javaInstance
to coerce their arguments to java. Trying to put a lisp object in a
java array throws an exception.
I think I know what needs to be done: Create parallel versions of
jcall, jstatic, and friends that don't do that and make them
available. That's a mod to Java.java.
If folks are comfortable with this I will make the additions and send
it to the list to have it update the current Java.java
The code I am talking about, BTW, looks like this currently:
Object[] methodArgs = new Object[args.length-2];
Class[] argTypes = m.getParameterTypes();
for (int i = 2; i < args.length; i++) {
LispObject arg = args[i];
if (arg == NIL)
methodArgs[i-2] = null;
else
methodArgs[i-2] = arg.javaInstance(argTypes
[i-2]);
}
Object result = m.invoke(null, methodArgs);
I would make new, additional versions, that don't do this coercion.
-Alan
On May 3, 2007, at 6:00 AM, Alex Mizrahi wrote:
> (message (Hello 'Alan)
> (you :wrote :on '(Wed, 2 May 2007 15:43:56 -0400))
> (
>
> AR> Say to store it in a java array of Object and retrieve it later?
>
> i think easiest way would be to wrap it in a CONS. or if you
> prefer, in to
> array -- you can create an array using jnew-array..
> there is also java.lang.ref.Reference class, but it's weird..
>
> )
> (With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
> "I am everything you want and I am everything you need")
>
>
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> armedbear-j-devel mailing list
> armedbear-j-devel@...
> https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel

(message (Hello 'Alan)
(you :wrote :on '(Thu, 3 May 2007 12:13:55 -0400))
(
AR> Sample code would be good. I don't think that this works. All calls
AR> go through jcall, jstatic etc, all of which seem to call javaInstance
AR> to coerce their arguments to java. Trying to put a lisp object in a
AR> java array throws an exception.
AR> I think I know what needs to be done: Create parallel versions of
AR> jcall, jstatic, and friends that don't do that and make them
AR> available.
i think it's better to extend make-immediate-object to allow making wrappers
over lisp objects.
jcall and friends will dereference that wrapper and pass lisp object to a
function that accepts java.lang.Object.
you can put that wrapped object in array. there should be no problems
passing that array.
in make-immediate-object there is such fragment:
if (type == Keyword.REF) {
if (object == NIL)
return new JavaObject(null);
else
throw new Error();
}
maybe instead of throwing error it can make new JavaObject(object).
or maybe it's better to make a separate type RAW for such case.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")

On Wed, 2 May 2007 at 15:43:56 -0400, Alan Ruttenberg wrote:
> Say to store it in a java array of Object and retrieve it later?
Maybe wrap it in a JavaObject:
CL-USER(1): (make-immediate-object 42)
#<JAVA-OBJECT java.lang.Integer {37FCD402}>
CL-USER(2): (jobject-lisp-value *)
42
I haven't tried, but I would think that you could pass a JavaObject to
a Java procedure and retrieve it later.
As an aside, I must apologize once again for my nearly-complete
ignorance of ABCL's Java FFI.
I'm no longer much of a Java programmer. ABCL and J are the only Java
programs I've worked on in the last six years, and I no longer work on
either of these on a daily (or even weekly) basis, apart from verifying
occasionally that ABCL can still build SBCL.
Although it's true that once upon a time I did write some of the
simpler parts of ABCL's Java FFI, but that was long ago, and I've
pretty much forgotten everything I used to know about it.
And I've never, ever, even once, used any of the more advanced features
of ABCL's Java FFI.
So I'm not really competent to judge the merits of any non-trivial
patch in this area. I'll try to respect the consensus of knowledgeable
folks who are really using this stuff.
-Peter