ClassCastException on collection generics for jdk8 working code
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Sat Jan 17 21:44:49 UTC 2015
Hi,
I think 8043741 got integrated in b46, so I would rule that one out
(also judging from the fix [1], which seems very localized to the
synthetic nullcheck operators). We'll need to dig a bit deeper on this
one - the behavior seems a bit weird, and I'm not sure this is intentional.
I'll keep you posted - I agree with Remi that compiler-dev is the right
mailing list for this one.
Thanks
Maurizio
On 17/01/15 20:22, Remi Forax wrote:
> 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 jdk9-dev
mailing list