Are classes generated by LambdaMetafactory special?
raffaello.giulietti at gmail.com
Mon Aug 5 21:51:41 UTC 2019
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.
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.
> ----- 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?
>> experiment suggests that classes generated by
>> java.lang.invoke.LambdaMetafactory are somewhat special:
>> (1) getName() on the class returns a string of the form
>> 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?
More information about the core-libs-dev