javac blames legal class files as "bad class file"

[Stephan Herrmann]

Hi Chen Liang

Thanks for commenting.

Am 20.06.24 um 16:40 schrieb 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.

Disclaimer: I don't know much about the needs of core reflection. As much as 
possible I try to work from specifications :)

> 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 read JVMS §4.7.19. as saying that this exact size mismatch is legal:
"num_parameters
     ...
     There is no assurance that this number is the same as the number of 
parameter descriptors in the method descriptor."

javac seems to rely on this very assurance that is explicitly not given.

> I recommend ecj to emit either Signatures (marking synthetic parameters) 

I believe this would violate JVMS §4.7.19:
"... A Signature attribute stores a signature (§4.7.9.1) for a class, interface, 
constructor, method, field, or record component whose declaration in the Java 
programming language uses type variables or parameterized types."

enums are not parameterized, they only extend a parameterized supertype, but 
that doesn't make the enum parameterized, it has no type variables.

> or MethodParameters to help javac categorize the parameters,

Users can enable this as an option (is this attribute mandatory in any way?), 
but even with MethodParameters generated, javac fails to read the class file.
In my book this is a bug.

Am I reading the spec in a wrong way?

For the future, perhaps making MethodParameters mandatory for specific 
situations would be a great enhancement for JVMS to make all parties happy?

At that point perhaps this from 4.7.24 should be changed, too: "The i'th entry 
in the parameters array may or may not correspond to the i'th type in the 
enclosing method's Signature attribute (if present), or to the i'th annotation 
in the enclosing method's parameter annotations."

But for now we only have the existing JVMS as point of reference.

> Regards,
> Chen Liang

thanks,
Stephan

> --------------------------------------------------------------------------------
> *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 
> <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://bugs.eclipse.org/bugs/show_bug.cgi?id=388314>
> - https://github.com/eclipse-jdt/eclipse.jdt.core/issues/205 
> <https://github.com/eclipse-jdt/eclipse.jdt.core/issues/205>
> 
> regards,
> Stephan