Lambda class names no longer reported when listening for JVMTI_EVENT_CLASS_FILE_LOAD events

[John Rose]

On Jan 22, 2014, at 4: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.

Background on anonymous classes:

They are a private feature of the HotSpot JVM implementation.  Naturally, compilers and other tightly-coupled tools have to know about them.

They don't have names, at least in the sense of something you could use to look up via a class loader.  What names they display are (as you see) derived from their bytecodes, but they do not function as regular class names.

Specifically, if someone tries to use the supposed name of an anonymous class with Class.forName or ClassLoader.loadClass, the result will be ClassNotFoundException.

The mangled suffix /XXXXX on Class.getName string provides an extra hint as to what is wrong.  (The XXXXX value happens to be the class's hash code, which makes it easier to distinguish classes with the same supposed name.)  Since slash '/' is an illegal element of class names, there's no ambiguity about how the name got that way.

HTH

— John

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