What I see happening here is that compiler doesn't completely follow equivalence of byte[] and ByteArray?. I'm pretty sure something similar can happen with maps and closures.
brianMon 30 Aug 2010
Promoted to ticket #1190 and assigned to brian
That probably isn't a compiler issue - the fcode the compiler generates for that looks correct:
This problem is probably associated with the fact that we changed the implementation of List to use a typed array backing store to catch runtime type errors. That code needs to be enhanced to handle these special interop JavaTypes.
brianWed 8 Sep 2010
Ticket resolved in 1.0.55
I reworked the Java runtime a bit to consistently handle primary arrays such that the Fantom reflection representation of a class like byte[] (which is really [B) will always be [java]fanx.interop::ByteArray.
vkuzkokov Sun 29 Aug 2010
Code:
gives interesing CE:
Workaround is:
What I see happening here is that compiler doesn't completely follow equivalence of
byte[]
andByteArray?
. I'm pretty sure something similar can happen with maps and closures.brian Mon 30 Aug 2010
Promoted to ticket #1190 and assigned to brian
That probably isn't a compiler issue - the fcode the compiler generates for that looks correct:
This problem is probably associated with the fact that we changed the implementation of List to use a typed array backing store to catch runtime type errors. That code needs to be enhanced to handle these special interop JavaTypes.
brian Wed 8 Sep 2010
Ticket resolved in 1.0.55
I reworked the Java runtime a bit to consistently handle primary arrays such that the Fantom reflection representation of a class like
byte[]
(which is really[B
) will always be[java]fanx.interop::ByteArray
.changeset