Lambda class names no longer reported when listening for JVMTI_EVENT_CLASS_FILE_LOAD events

[Brian Goetz]

Yes, the numbers after the slash are added by the anon class loader.  

Sent from my iPhone

On Jan 22, 2014, at 7:05 PM, "Frost, Gary" <Gary.Frost at amd.com> wrote:

> Hey Brian
> 
> After a bit of poking around I notice that if I turn on 
> 
> -verbose
> 
> The JVM reports loading the class I am interested in. 
> 
> I also noticed that the classes are passed to the JVMTI callback handler,  however the name is no longer passed, instead we seem to be passing NULL. 
> 
> Of course I have the bytes to the class being passed to my JVMTI handler ;) so when I dive into the classbytes I can indeed match the classname (sort of - see below). 
> 
> It looks like we are still passing the classbytes, we just chose to not pass the name.  Seemingly to make life a littl harder ;) for us Aparapi folk.
> 
> BTW I do note that there is some other  naming weirdness.  
> 
> These classes used to be called something like 
> 
> mypackage.MyClass$$lambda$1
> 
> Now the reflected classname of the implementation of IntConsumer (the lambda I am trying to get bytes for) is now 
> 
> mypackage.MyClass$$Lambda$1/XXXXX (where XXXXX is some 5 digit integer)
> 
> Whereas if I extract the name of the class from the bytes of the class the name is still 
> 
> mypackage.MyClass$$lambda$1
> 
> So whoever is composing this synthetic named class, seems to be encoding a different name in the class, than the name itself.  That seems scary. 
> 
> Gary
> 
> ________________________________________
> From: Brian Goetz [brian.goetz at oracle.com]
> Sent: Thursday, January 23, 2014 7:48 AM
> To: Frost, Gary
> Cc: lambda-dev at openjdk.java.net
> Subject: Re: Lambda class names no longer reported when listening for JVMTI_EVENT_CLASS_FILE_LOAD events
> 
> Yes.  We moved to "anonymous classes" (in the sense of Unsafe.defineAnonymousClass, not anonymous inner classes), for reasons of both security and performance.  This is an unfortunate side effect.
> 
> On Jan 22, 2014, at 5:33 PM, Frost, Gary wrote:
> 
>> Not sure when this change came about but I just started using
>> 
>> java version "1.8.0-ea"
>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b124)
>> 
>> I noticed that the JVMTI agent I use to  listen for JVMTI_EVENT_CLASS_FILE_LOAD events is no longer seeing events for the dynamically create classes created to encapsulate 'captured' args.  Or possibly the class events are triggeted, but the 'name' is NULL. I am seeing an increase in the number of a events reported NULL as the name.
>> 
>> The Aparapi project listens for these events so we can determine the captured args for a given lambda.  These are the synthetic classes created on the fly by the method handle factory.
>> 
>> This had been working fine until recently.  Is there a reason we would stop generating  these, or is this just a regression?
>> 
>> Gary
> 
> 
>