RFR: 8357016: Candidate main methods not computed properly [v2]

[Jaikiran Pai]

On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> A consider class like this:
>> 
>> 
>> public class TwoMains {
>>     private static void main(String... args) {}
>>     static void main() {
>>         System.out.println("Should be called, but is not.");
>>     }
>> }
>> 
>> 
>> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored.
>> 
>> Something similar happens if the return type is not `void`.
>> 
>> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable.
>> 
>> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated).
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding tests as suggested.

I went through the JLS updates linked in the CSR for JEP 512 https://bugs.openjdk.org/browse/JDK-8353437. The proposed changes in this PR looks good to me. The additional test coverage being added is good too.

I am not completely sure if the `Arrrghs.java` test and the `test/jdk/tools/launcher/InstanceMainTest.java` test fully cover all the scenarios of the new rules of determining a main method, but that's something that can be looked into as a separate activity.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25256#issuecomment-2886504200