Thanks for the explanation, Chen. I was confused by the javadoc on defineClass, as it states that references would also be redirected during verification. I now see that class loads during verification are irrelevant here. I was also unaware that the receiver of field and method references were directly referring to thisClass (mostly due to never manually reading the constant pool and just relying on disassemblers to combine the entries) which made me believe they were replaced differently.
I'll probably move my setup over to using custom classloaders, as I will need to be able to use lambdas. I don't think I can do any bytecode patching here as I can't get the runtime name before the jvm has already loaded the class (and I'm already generating it with ASM so I have full control over the bytecode). Being able to do more with indy in hidden classes would be nice, but I will for the foreseeable future be stuck on java 21, so any new progress won't be affecting me anyway. I now see that there was no bug or oversight and that I simply misunderstood documentation and behaviour. Thanks for your time, Matias On Tue, Sep 10, 2024 at 4:47 PM Chen Liang <chen.l.li...@oracle.com> wrote: > 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 > > >
