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

Mark Evenson evenson at panix.com
Tue Jun 14 10:49:13 UTC 2011

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)
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."

More information about the armedbear-devel mailing list