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.giulie...@gmail.com>
À: "core-libs-dev" <core-libs-dev@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
