On Fri, 5 May 2023 09:43:04 GMT, Jaikiran Pai <[email protected]> wrote:
>> Jim Laskey has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Anonymous main classes renamed to unnamed classes
>> - Add test
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 70:
>
>> 68: correctArgs(method) &&
>> 69: // Only statics in the declaring class
>> 70: (!isStatic(method) || declc == refc)
>
> Should this also exclude `abstract` and `native` methods named `main`?
abstract would be overshadowed by its implementation and native is fair game.
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134:
>
>> 132:
>> 133: /**
>> 134: * {@return priority main method or null if none found}
>
> I think this javadoc is perhaps outdated? The current implementation of this
> method throws a `NoSuchMethodException` when it can't find any eligible main
> method.
Changing
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 152:
>
>> 150:
>> 151: List<Method> mains = new ArrayList<>();
>> 152: gatherMains(mainClass, mainClass, mains);
>
> The `try` block above is there to find `public static void main(String[])` in
> the launched class. When it's not found, then we gather the potential main
> methods (as listed in the JEP). The implementation of `gatherMains(...)`, in
> its current form starts gathering the main methods from
> `refc.getSuperclass()`, where `refc` in this case is the `mainClass`, which
> is the launched class.
>
> So if I'm reading this correctly, then I think it's going to completely skip
> the launched class for looking any potential main methods and instead start
> looking for them in the launched class' super hierarchy.
It doesn't skip, it just adds the super members first. However, I should move
the `gatherMains` to the end since the sort pushes the best candidate to the
top and (was originally taking the last one with an opposite sort order). The
sort order is
- static trumps non-static
- public trumps protected/package-protected
- arguments trumps no arguments
- depth in hierarchy
Let's say we have a hierarchy of `B` inherits from `A`. If `B` contains
`public void main()` and `A` contains `public void main(String... args)`,
`A`'s `main` trumps `B` `main` since it has arguments.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186247702
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186249703
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186245072
