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