ClassCastException on collection generics for jdk8 working code

[Srikanth]

Hello !

I have raised https://bugs.openjdk.java.net/browse/JDK-8069265 to track 
this one.
This new behaviour got introduced as of JDK9 build b08 as a result of 
the change
made for https://bugs.openjdk.java.net/browse/JDK-8015499.

Prima facie, there is no indication that there is a compiler bug here. 
The compiler
is well within its rights to assert what it is asserting which fails due 
to CCE. But
we may want to see if we should/could avoid such gratuitous and 
inadvertent behaviour
change.

Thanks!
Srikanth

-------- Forwarded Message --------
Subject: 	Re: ClassCastException on collection generics for jdk8 working 
code
Date: 	Sat, 17 Jan 2015 21:44:49 +0000
From: 	Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
To: 	Remi Forax <forax at univ-mlv.fr>, compiler-dev at openjdk.java.net
CC: 	jdk9-dev at openjdk.java.net



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
>>>
>>>
>>>
>