On Fri, 5 May 2023 09:43:04 GMT, Jaikiran Pai <j...@openjdk.org> 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