Where to ask about a potential bug/oversight with hidden classes

[Matias Koivikko]

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.liang at 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-retn at openjdk.org> on behalf of Matias Koivikko <
> matias.koivikko at gmail.com>
> *Sent:* Tuesday, September 10, 2024 7:35 AM
> *To:* discuss at openjdk.org <discuss at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240910/c1910b15/attachment.htm>