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