On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda <[email protected]> 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:
>
> Review comment: correcting typo.
test/jdk/tools/launcher/Arrrghs.java line 649:
> 647: """);
> 648: tr = doExec(javaCmd, "-jar", "some.jar");
> 649: tr.contains("Error: abstract class Foo can not instantiated");
After the latest typo fix, this check would also need an update.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092905785
