On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda <jlah...@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.
src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283:
> 281: make inner class static or move inner class out to separate source
> file
> 282: java.launcher.cls.error8=\
> 283: Error: abstract class {0} can not instantiated\n\
typo: can not `be` instantiated
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092862512
