[armedbear-devel] How to create a byte[] from a Lisp vector? (was Re: MAKE-IMMEDIATE-OBJECT and JOBJECT-LISP-VALUE conceptual problem)

[Mark Evenson]

On 6/11/11 09:06 , Alan Ruttenberg wrote:
> I've always disliked make-immediate-object. Really it serves the
> purpose of disambiguating a few overloaded values in lisp. I'd like to
> deprecate it in favor of specific constants for java-true, java-false
> and null-pointer (the latter is already available as function).

Unless anyone speaks up against this, I will make this change to the 
Java API.

> It seems dangerous to assume that one can get some java array as the
> underlying object below a lisp array, what with all the hair that lisp
> arrays can have.  Better to allocate your buffer with (jnew-array
> "byte" 8192) and not get into this game. Or have a documented policy
> of how java objects correspond to lisp objects and promise to support
> it forever.

I agree that we probably shouldn't go down the path of exposing the 
"internal" byte array here.

But I still couldn't find a way to covert a Lisp array of en masse to a 
Java byte[] structure.

One can't construct a byte from a Lisp integer with JAVA:JNEW

CL-USER> (jnew "byte" 0)

fails with #<JAVA-EXCEPTION java.lang.NoSuchMethodException: 
byte(java.lang.Integer) {39397F0A}>.

Same for

CL-USER> (jnew "java.lang.Byte" 0)

for the same reason.

One can use the Byte(string) constructor

CL-USER> (jnew "java.lang.Byte" "0")

but that seems kludgy in the extreme.  Does anybody have a way to create 
a JAVA-OBJECT containing a byte?  Did I miss something basic?

And JNEW-ARRAY-FROM-ARRAY on a Lisp vectors of numbers also fails, so 
there really seems to be another lacunae in our API.

In order to work through this, I modified ABCL in [r13327]() and 
[r13328]() to get

CL-USER> (jcoerce 0 "byte")

to return a "boxed" byte.

and added the ability to form a byte[] from the appropriate Lisp vector.

CL-USER> (type-of buffer)
(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (8192))
CL-USER> (jnew-array-from-array "byte" buffer)
#<jarray [B at 61d60df3 {2C2DFEB3}>

[r13327]: http://trac.common-lisp.net/armedbear/changeset/13327
[r13328]: http://trac.common-lisp.net/armedbear/changeset/13328

The conversion maps any number to its signed twos-complement value 
modulo 256, which I think is the right thing.

Please pipe up if this is the wrong way to move the ABCL Java API 
forward to more usability.

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."