On Tue, Mar 23, 2010 at 6:55 AM, Mark Evenson evenson@panix.com wrote:
On 3/23/10 7:21 AM, dmiles@users.sourceforge.net wrote: […]
A commiter should be able to help
Patched as suggested in [r12570][1], although I am not entirely happy with this change yet (see below).
Thanks, that fixes my trouble.
As far as I understand this problem, the insertion/removal of the byte[] from the Java collection has erased the type information down to java.lang.Object. This type is "good enough" for the current constructors of JAVA-OBJECT (after all java.lang.Object is a valid type), but causes problems when being asked to return a Java reference in compiled Java code (like that in the SYS::%MAKE-BYTE-ARRAY-OUTPUT-STRING.)
My hunch is that need to tighten the JAVA-OBJECT constructors to check if they are being asked to wrap an array of primitive type, adjusting the value of intendedClass if this is the case. I'm reluctant to make such a change as a) I don't fully understand the ramifications of the difference between Class.isInstance() and Class.isAssignableFrom(), b) don't know if this only fails for arrays of primitive type, and c) don't have enough test coverage to judge such things quickly.
Comments and advice solicited.
intendedType ends up as java.lang.Object for any java object I move into and out of an ArrayList -- not just arrays. As far as I can tell, lisp objects move back and forth with no trouble, (inspect ..) does not show any difference for a hash table I move back and forth, but (inspect ..) does show that a java.io.File moved back and forth ends up with a changed intendedType.
I'm doing a lot of this sort of thing, and the example with sys::%make-byte-array-output-string is the only thing that gave me trouble. Even when a java.io.File ends up with Object as it's intendedType, it still works fine with (jcall ...). I assume that there would only be trouble when JavaObject.javaInstance() is called, which is apparently not that often!
-david k.