Lambda class names no longer reported when listening for JVMTI_EVENT_CLASS_FILE_LOAD events

[Frost, Gary]

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
>