[armedbear-devel] Losing type information after storing in java.util.ArrayList
dkirkman at ucsd.edu
Tue Mar 23 16:58:32 UTC 2010
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], although I am not entirely happy
> with this change yet (see below).
> : 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
> 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
fine with (jcall ...). I assume that there would only be trouble when
JavaObject.javaInstance() is called, which is apparently not that often!
More information about the armedbear-devel