ClassCastException on collection generics for jdk8 working code
Remi Forax
forax at univ-mlv.fr
Sat Jan 17 20:22:44 UTC 2015
I think this is due to the fix of 8043741 [1].
In my opinion, these legacy tests are buggy and because of a bug in the
compiler
it was working, and not the other way around.
Anyway, it's just my opinion, there is a lot of corner cases around the
cast to an interface,
asking the experts is a better idea so I've CC compiler-dev.
Rémi
[1] https://bugs.openjdk.java.net/browse/JDK-8043741
On 01/17/2015 07:51 PM, Emanuel wrote:
> Thank you Martijn, i didn't know :)
>
> here we go :
> https://gist.github.com/tglman/02eb98fb1c80386fa3ab
> https://gist.github.com/tglman/44b0b3fc4239d9229027
>
> Let me add also that OrientDB don't rely in any way on this behavior, it
> come out just from two not well written legacy test case ;).
>
> On 01/17/2015 05:11 PM, Martijn Verburg wrote:
>> Hi Emanuel,
>>
>> Good to see you today! OpenJDK mailing lists strip attachments so
>> you'll need to give a pastebin link or similar.
>>
>> Cheers,
>> Martijn
>>
>> On 17 January 2015 at 16:58, Emanuel <emanuele.tagliaferri at gmail.com
>> <mailto:emanuele.tagliaferri at gmail.com>> wrote:
>>
>> I am at the Adopt OpenJdk hack day organized by the LJC, I am running
>> tests cases of OrientDB (open source java based NoSql) on JDK9 (Build
>> b45 ), and i got some issue with the use of generics.
>>
>> basically this code:
>> List<Date> list = new ArrayList<>();
>> list.add(new Date());
>>
>> List<Foo> cList = (List<Foo>) (List<?>) list;
>> Date date = (Date) cList.get(0); // it
>> fail here
>>
>> on jdk8 it work fine, on jdk9 the code fail in the marked line.
>>
>> the jdk8 bytecode for the failing line is:
>> invokeinterface #7, 2 // InterfaceMethod
>> java/util/List.get:(I)Ljava/lang/Object;
>> checkcast #4 // class java/util/Date
>>
>> instead of on jdk9 is:
>> invokeinterface #7, 2 // InterfaceMethod
>> java/util/List.get:(I)Ljava/lang/Object;
>> checkcast #8 // class ListFail$Foo
>> checkcast #4 // class java/util/Date
>>
>>
>> and is clear that there's a additional cast that is causing the
>> exception.
>>
>> I understand that this code is not the exactly clean and correct
>> conceptually, but it may be a lot of this staff out there that can be
>> break by jdk9.
>>
>> In attachment a couple of simple example for reproduce this issue.
>>
>>
>> Regards
>>
>> Emanuel
>>
>>
>>
More information about the compiler-dev
mailing list