ClassCastException on collection generics for jdk8 working code

[Maurizio Cimadamore]

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