This is not true. Trying to compile this code gives the following error

Test.java:1: error: compact source file does not have main method in the form of void main() or void main(String[] args)
int main() { return 0; }

Related to the above, the problem reporting is wrong. Main methods may only have a 'void' return type.

This test is very similar to the simpleMainMethod above. I think this can be removed if you move the assertFalse(mainMethod.isStatic(), "Main method can be instance in JEP 512"); check to that method.

Please add a parameter corresponding to this field to the @AllFieldsConstructor annotated constructor since this is used for code generation and it's currently not possible to create an instance of a compact ClassOrInterfaceDeclaration without a separate setCompact call.

To avoid requiring users to modify existing code, it may be necessary to add another constructor with the same parameter list as the current AllFieldsConstructor. I'd like input from the project maintainer @jlerbsc about this, however, since adding another constructor for each added field could lead to a lot of bloat over time and make it more difficult for users to figure out which constructor should be used. Requiring users to potentially update the majority of their constructor invocations to support a field that is only relevant in a small minority of cases feels very disruptive, however.

To avoid requiring users to modify existing code, it may be necessary to add another constructor with the same parameter list as the current AllFieldsConstructor. I'd like input from the project maintainer @jlerbsc about this, however, since adding another constructor for each added field could lead to a lot of bloat over time and make it more difficult for users to figure out which constructor should be used. Requiring users to potentially update the majority of their constructor invocations to support a field that is only relevant in a small minority of cases feels very disruptive, however.

As you pointed out, I think we need to add a new constructor that will be referenced by all the others. I don't think there will be many more changes to this class in the future, and this will have less impact on code using JavaParser.

It is not correct to validate every method called main this way. JEP 512 only requires that a main method with a valid "main" signature exists in a compact class, not that every main method has such a signature. I'm not sure whether this is something we even need a validator for, however. As far as I understand, the point of the validators is not to re-implement the java compiler's error checking, but rather to report when language features not matching the selected version are used. Methods called main with any signature are already allowed in general. The signature of the main method only matters when trying to determine the entry-point for the program, which isn't something JavaParser attempts to do in general. We also assume that input code compiles, so checking the signature of main is redundant.

Example 1 does not compile

void main(String[] args, int x) { }

Example 2 does compile

void main(String[] args, int x) { }

void main(String[] args) { }

Example 3 does compile

class Foo {
  // This isn't a valid entry point into the application, but is a valid method regardless
  void main(String[] args, int x) { }
}

We also assume that input code compiles

That is indeed a requirement.

I do not think a complex validator is needed here (see my comment below for more of a discussion about why). Instead, I think a Java1Validator should be added to validate that no compact classes are created and then that validator should be removed here since that feature is available for Java versions >= 25. Checking details like whether the compact class extends other classes is effectively just checking for JavaParser bugs and should rather be covered by unit tests. Checking whether a valid main method exists is the responsibility of the java compiler and JavaParser assumes any input code compiles, so checking that is redundant.

This isn't correct. With the way compact classes are handled here

void main() {}

class Foo {}

will effectively be represented as

class UnnamedClass {
  void main() {}
}

class Foo {}

when it should be represented as

class UnnamedClass {
  void main() {}

  class Foo {}
}

The explanation for this is in https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.1.8

The body of the class contains every class member declared in the compact compilation unit (these are declarations of fields (§8.3), methods (§8.4), member classes (§8.5), and member interfaces (§9.1.1.3)). It is not possible for a compact compilation unit to contain declarations of instance initializers (§8.6), static initializers (§8.7), or constructors (§8.8).

where

A member class is a class whose declaration is directly enclosed in the body of another class or interface declaration

Helper should be a nested class in the compact class. See my comment on the java.jj changes for a more detailed explanation.

I can see 2 issues here:

1. I'm not sure if the empty string is a good name to use. It makes the naming of nested classes awkward. I think that keeping a placeholder name would be better for consistent naming (but this is subjective so please share your thoughts on this @jlerbsc)
2. Overriding the name here is very brittle. compactClass.getName().toString() still returns $CompactClass, for example. I assume the pretty printer and various other mechanisms to get a string representation for the class would have the same issue.

Does the JLS specify anything on this subject? Perhaps a test on a compact class containing an included class could improve our understanding of what needs to be done.

JEP 512 says the following:

A compact source file declares a class implicitly, so the class does not have a name that can be used in source code. The Java compiler generates a class name when compiling a compact source file, but that name is implementation-specific and should not be relied upon in any source code — not even source code in the compact source file itself.

OpenJDK defaults to using the source filename for the class name which is a sensible choice consistent with Java convention, but that information won't always be available. Perhaps an approach where we use the filename if it is available, otherwise fall back to some (perhaps configurable) default naming scheme could work.

This should not be changed. Please review the generated code before pushing it.