Hi Matias, Since MethodHandles is a library API, I think we can discuss about this on core-libs list.
About the self-reference replacement: as the spec says, it only happens to the thisClass Class entry in the hidden class. That means if the class is referenced in a method (such as a method's parameter in your class) or field (such as a field's type in your class) descriptor, all of which do not go through Class entries, the reference is kept as-is. So the lack of substitution for NameAndType is working as intended. Currently, LambdaMetafactory only has limited support for static methods in hidden classes, which was actually not available in release 22 and only added in release 23 development as there's a need from project Babylon. This is not part of LMF's specification and we might adjust this behavior at any time. For your purpose, you might have to bytecode process the class and patch references manually, or look into using non-hidden classes in custom class loaders instead. Regards, Chen ________________________________ From: discuss <discuss-r...@openjdk.org> on behalf of Matias Koivikko <matias.koivi...@gmail.com> Sent: Tuesday, September 10, 2024 7:35 AM To: disc...@openjdk.org <disc...@openjdk.org> Subject: Where to ask about a potential bug/oversight with hidden classes Hi everyone, I've been working on a project where I compile custom code to class files and load them using MethodHandles.Lookup#defineHiddenClass into the jvm. This seems like the correct method to me as my classes don't need to be referenced from the outside beyond reflectively calling a single method and they should ideally unload soon after unless they stored references somewhere. As for the bug, it involves lambdas that capture this and a ClassNotFoundException being thrown for the hidden class. As far as I understand it, the hidden class gets a randomized name at runtime and all references to itself within the class file should be replaced. It seems like this process doesn't work properly for the main NameAndType of an invokedynamic instruction. This would then cause a runtime crash whenever capturing lambdas among other uses of indy are used. Does anyone have any ideas on what I could have done wrong or where I should take this question further? I assume there's some more appropriate mailing list to discuss this issue in. Regards, Matias
