[armedbear-devel] Losing type information after storing in java.util.ArrayList

[David Kirkman]

On Tue, Mar 23, 2010 at 6:55 AM, Mark Evenson <evenson at panix.com> wrote:
> On 3/23/10 7:21 AM, dmiles at 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).
>
> [1]: http://trac.common-lisp.net/armedbear/changeset/12570
>

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.