Analyze jdk classes through reflection instead of asm

[sfPlayer1]

This already seems to be enough to make MC 1.21.1 run with Java 23, Fabric API and an ASM version incompatible with the active JDK.

It doesn't look like Mixin needs any of the non-populated data, I probably already fill in more than necessary. It is assumed that mixins can't target jdk classes, but Mixin doesn't seem to give good early errors for this, I think it'd end up silently ignoring those targets as they wouldn't go through Knot in the first place. Improving that is out of scope for this change.

[LlamaLad7]

Could this at least be a fallback, used only if the current JDK is newer than ASM supports?

[modmuss50]

Could this at least be a fallback, used only if the current JDK is newer than ASM supports?

My only worry with that is it that it would only be exercised in the rare situation when a newer Java version is used, thus its unlikely it will be regularly tested. What would be the argument against using this all the time, are you worried about peformance?

[LlamaLad7]

Mainly just worried about the unpopulated data. It may well not be used by Mixin itself but other mods are perfectly free to use ClassInfo and regularly do so. If the data is available via reflection I'd prefer it to be populated.

[sfPlayer1]

It should perform better than analyzing the class, I think if mixin accesses any of the missing data there's a bug elsewhere. I noticed that Mixin is not too eager to initialize everything everywhere itself, imo it's fair to change the expectations a little unless we find actual breakage in the field.

[Oregano1963]

Any updates on this situation?