l 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
>>>
>>>
solution was to mark those
classes as non-modifiable. This may change in the future.
Rémi
- Mail original -
De: "raffaello giulietti"
À: "core-libs-dev"
Envoyé: Lundi 5 Août 2019 23:02:48
Objet: Are classes generated by LambdaMetafactory special?
Hello,
experiment s
those classes as non-modifiable. This may
change in the future.
Rémi
- Mail original -
De: "raffaello giulietti"
À: "core-libs-dev"
Envoyé: Lundi 5 Août 2019 23:02:48
Objet: Are classes generated by LambdaMetafactory special?
Hello,
experiment suggests th
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"
> À: "core-libs-dev"
> Envoyé: Lundi 5 Août 2019 23:02:48
&
This is intentional. The lambda proxy classes are defined as VM
anonymous classes through a JDK internal API
Unsafe::defineAnonymousClass. These generated classes are JDK
implementation details that are hidden for any class lookup and not
modifiable by JVM TI agent.
JDK-8171335 is the RFE
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
