Type variable information is not always maintained for anonymous classes

[David Holmes]

Hi Sergey,

I've had a look and I don't think this issue is relevant to JDK-8171335. 
The problem seems to occur when you have a "hidden" enclosing context 
for the type, and that doesn't change with JDK-8171335.

David

On 9/12/2018 6:04 am, Sergey wrote:
> Hi David,
> 
> Thanks for pointing that out!
> 
>  >We need to see how this example work in that case.
> 
> I guess anyone involved could have straight away two
> test cases: one from the bug itself and another from the
> observation above.
> 
> In any case. looking forward for that being fixed. I would
> also be happy to be able to help with anything if needed.
> 
> Thanks and regards,
> Sergei
> 
> On Sat, 8 Dec 2018 at 12:03, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Sergey,
> 
>     Just FYI we're in the process of moving away from using anonymous
>     classes for lambda's to using an extended Lookup.defineClass API - see:
> 
>     https://bugs.openjdk.java.net/browse/JDK-8171335
> 
>     this is being done under Project Valhalla, with current work in the
>     nestmates branch.
> 
>     We need to see how this example work in that case.
> 
>     Cheers,
>     David
> 
>     On 8/12/2018 9:53 am, Sergey wrote:
>      > Hi everyone,
>      >
>      > Recently I've stumbled upon this bug
>      > https://bugs.openjdk.java.net/browse/JDK-8213465
>      > which is named the same way as in the header of an email. I've done a
>      > little bit of
>      > investigation and keen to fix it. Though I'm afraid that most
>     likely fix
>      > wouldn't be just
>      > a one-liner. Thus I want to ask for a little bit of a guidance
>     and make
>      > sure, that I do not cross
>      > anyone else. With that being said, if ticket isn't in progress
>     and no one
>      > minds I want to make
>      > an attempt on it.
>      >
>      > Thanks and regards,
>      > Sergei
>      >
>