javac blames legal class files as "bad class file"

[Chen Liang]

Hi Stephan,
I believe the reason javac required Signature attribute was that enum constructors always had 2 leading synthetic name and ordinal parameters, yet they couldn't be marked so until MethodParameters attributes are introduced in 8. And core reflection assumes the annotations don't appear on implicit (mandated) or synthetic parameters.

I javap disassembled the eclipse jdt output at Enumerations incompatible with "javac" · Issue #205 · eclipse-jdt/eclipse.jdt.core (github.com)<https://github.com/eclipse-jdt/eclipse.jdt.core/issues/205#issuecomment-1960748768>, and found that it emits neither MethodParameters nor Signature attributes on the constructor. Then it makes sense for core reflection and javac to consider there's a size mismatch between RuntimeInvisibleParameterAnnotations attribute (3)and the method parameter list (5). I recommend ecj to emit either Signatures (marking synthetic parameters) or MethodParameters to help javac categorize the parameters, and then report the problems with javac and core reflection on identification of these parameters.

Regards,
Chen Liang
________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Stephan Herrmann <stephan.herrmann at berlin.de>
Sent: Thursday, June 20, 2024 4:42 AM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: javac blames legal class files as "bad class file"

This is a friendly reminder that https://bugs.openjdk.org/browse/JDK-8024694 is
still causing grief.

In particular, Eclipse keeps receiving bug reports because javac claims that
class files created by ecj are "bad".

Latest analysis indicates that this wrong blame could be the result of an
internal AIOOBE that javac catches and translates into a general, not helpful
error message.

To be explicit: comments in JDK-8024694 mostly discuss which attributes javac
should emit, which at this point is irrelevant for Eclipse. The original bug is
that javac should not expect all class files to follow the same convention in
situations where JVMS explicitly allows different strategies.

More details can be found around these reports:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=388314
- https://github.com/eclipse-jdt/eclipse.jdt.core/issues/205

regards,
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240620/c3b57b8f/attachment-0001.htm>