On 11/12/2018 4:27 pm, Sergei Ustimenko wrote:
Hi David,
Thanks for checking it, I'll continue working on it then.
Just wondering if you have any thoughts on how fix would
look like.
No. I tried tracking through the Java code to see how this works but the
path is too long and convoluted :( The information is correct in the
classfile, but somewhere along the way the nature of the enclosing type
affects the answer that is produced. See ParameterizedTypeImpl and how
it gets created by CoreReflectionFactory.
BTW as far as I can see it is not allowed for that method to produce
null: the type array can be empty, or creating it can throw an
exception, but otherwise the entries cannot be null.
Cheers,
David
Regards,
Sergei
On Tue, 11 Dec 2018 at 02:34, David Holmes <[email protected]
<mailto:[email protected]>> wrote:
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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>> 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
