On Fri, 20 Mar 2026 09:20:05 GMT, Jan Lahoda <[email protected]> wrote:
>> Consider these classes:
>>
>> package p;
>> public class Lib {
>> void main(String... args) {
>> System.err.println("Lib!");
>> }
>> }
>>
>> and:
>>
>> import p.Lib;
>> public class Main extends Lib {
>> public void main() {
>> System.err.println("Main!");
>> }
>> }
>>
>>
>> Note the classes are in different packages. Running this on JDK 26 yields:
>>
>> $ jdk-26/bin/java Main.java
>> Lib!
>>
>>
>> that is not correct - the method `Lib.main(String[])` is package private,
>> and is not inherited to `Main`, i.e. not a member of `Main`, and hence the
>> launcher should not use it. The launcher should only inspect methods that
>> are members (direct or inherited) of `Main`.
>>
>> This PR fixes that by only using package-private methods in they are
>> declared in the same class as is the main class. Testing is enhanced to
>> cover all related cases I/we were able to find.
>>
>> Also please review the corresponding CSR:
>> https://bugs.openjdk.org/browse/JDK-8378555
>
> Jan Lahoda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Using Class.getPackageName + Class.getClassLoader to detect runtime
> packages as suggested.
src/java.base/share/classes/jdk/internal/misc/MethodFinder.java line 114:
> 112: return Objects.equals(c1.getPackageName(), c2.getPackageName())
> &&
> 113: Objects.equals(c1.getClassLoader(), c2.getClassLoader());
> 114: }
The application class loader is well behaved so it doesn't matter too much but
it would be better to check that c1.getClassLoader() == c2.getClassLoader().
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30221#discussion_r2969319591
