Are classes generated by LambdaMetafactory special?

[Raffaello Giulietti]

Hi Mandy,

thanks for the deeper explanation: all this makes much sense.


Greetings
Raffaello


 >One property of a lambda proxy class is to be in the same nest as the
 >caller class as it's logically part of the caller class (as it may
 >access its private member).  VM anonymous class is an interim
 >implementation solution until we provide a way to define a dynamically
 >generated class as a nestmate of an existing class.
 >
 >Second property of proxy classes is that proxy classes are not
 >symbolically referenced by other class and they are sole implementation
 >of some methods or some classes/interfaces.  Proxy classes can be
 >defined as ordinary class while it has to ensure that the class name
 >must be unique in the global VM namespace. There is overhead generating
 >such a class to the system dictionary (not to mention loader
 >constraints).  OTOH the name of a proxy class is only useful for
 >troubleshooting but entirely not needed at runtime.
 >
 >Mandy
 >
 >On 8/5/19 2:51 PM, Raffaello Giulietti wrote:
 >> Thanks Rémi and Mandy.
 >>
 >> I still don't get the full rationale on why lambda classes should be
 >> treated so specially but at least I now understand the current behavior.
 >>
 >>
 >> Greetings
 >> Raffaello
 >>
 >>
 >>
 >>
 >> On 05/08/2019 23.34, Remi Forax wrote:
 >>> It is intentional and the implementation details are planned to
 >>> change in the future
 >>> (there are already some patches in the valhalla/nestmates branch).
 >>>
 >>> The slash in the name is because you can create several classes from
 >>> the same bytecode by patching it at runtime,
 >>> the number after the slash is for each patching.
 >>>
 >>> Unlike a classical class, the class is not stored by a classloader in
 >>> order to be garbage collected sooner, hence you can not find it this
 >>> Class.forName.
 >>>
 >>> Intrumentation of a lambda proxy tends to fail because there is no
 >>> API to get the patched data and because the class name is not
 >>> resolvable (see above) so the easier solution was to mark those
 >>> classes as non-modifiable. This may change in the future.
 >>>
 >>> Rémi
 >>>
 >>> ----- Mail original -----
 >>>> De: "raffaello giulietti" <raffaello.giulietti at gmail.com>
 >>>> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
 >>>> Envoyé: Lundi 5 Août 2019 23:02:48
 >>>> Objet: Are classes generated by LambdaMetafactory special?
 >>>
 >>>> Hello,
 >>>>
 >>>> experiment suggests that classes generated by
 >>>> java.lang.invoke.LambdaMetafactory are somewhat special:
 >>>>
 >>>> (1) getName() on the class returns a string of the form
 >>>>      Xxx$$Lambda$nn/0xhhh
 >>>> where Xxx is a fully qualified class name (with periods '.' as package
 >>>> separators), nn is a decimal integer and hhh is a hex integer. What's
 >>>> the role of the slash '/' in the name?
 >>>>
 >>>> (2) An invocation of Class.forName() with that name fails.
 >>>>
 >>>> (3) Invoking java.lang.instrument.Instrumentation.isModifiableClass()
 >>>> with that class as an argument returns false.
 >>>>
 >>>> Is this intentional or is it a bug?
 >>>>
 >>>>
 >>>> Greetings
 >>>> Raffaello
 >
 >