RFR: 8293977: jdk/modules/etc/VerifyModuleDelegation.java fail with jfx

[Leslie Zhai]

On Mon, 19 Sep 2022 06:14:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> @dumasun reported the issue:
>> 
>> Configured with jfx-ls-modular-sdk:
>> 
>> 
>> configure --with-import-modules=modular-sdk
>> 
>> 
>> `make run-test CONF=fastdebug TEST="jdk/modules/etc/VerifyModuleDelegation.java"` failed:
>> 
>> 
>> ----------System.out:(46/3114)----------
>> test VerifyModuleDelegation.checkJavaBase(): success
>> test VerifyModuleDelegation.checkLoaderDelegation(): failure
>> java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop
>>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$1(VerifyModuleDelegation.java:77)
>>     at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
>>     at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921)
>>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>     at VerifyModuleDelegation.lambda$checkLoaderDelegation$2(VerifyModuleDelegation.java:68)
>>     at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715)
>>     at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>     at VerifyModuleDelegation.checkLoaderDelegation(VerifyModuleDelegation.java:68)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>     at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>     at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>     at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>     at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>     at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>     at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>>     at org.testng.TestRunner.privateRun(TestRunner.java:764)
>>     at org.testng.TestRunner.run(TestRunner.java:585)
>>     at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>>     at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>>     at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>>     at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>>     at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>>     at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>>     at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>>     at org.testng.TestNG.runSuites(TestNG.java:1069)
>>     at org.testng.TestNG.run(TestNG.java:1037)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> ===============================================
>> jdk/modules/etc/VerifyModuleDelegation.java
>> Total tests run: 2, Passes: 1, Failures: 1, Skips: 0
>> ===============================================
>> 
>> ----------System.err:(13/753)----------
>> WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.concurrent
>> java.lang.Exception: failures: 1
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>>     at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54)
>>     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>>     at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>     at java.base/java.lang.Thread.run(Thread.java:1589)
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> I don't think the test should be changed list this until there is more information on the issue. jdk.unsupported.desktop should be mapped to the application class loader. Can you tell use which class loader that javafx.swing is mapped to? Has the module-loader-map.conf changed in your environment? I'm wondering if there is any residual configuration somewhere that is mapping the javafx.* modules the platform class loader.

Hi @AlanBateman 

Thanks for your kind response!

> Can you tell use which class loader that javafx.swing is mapped to?

According to the output:


java.lang.Error: platform/javafx.swing can't delegate to find classes from app/jdk.unsupported.desktop


app as the `loader2` that javafx.swing is mapped to:


    @Test
    public void checkLoaderDelegation() {
        ModuleLayer boot = ModuleLayer.boot();
        MREFS.stream()
             .forEach(md -> md.requires().stream().forEach(req ->
                 {
                     // check if M requires D and D's loader must be either the
                     // same or an ancestor of M's loader
                     ClassLoader loader1 = boot.findLoader(md.name());
                     ClassLoader loader2 = boot.findLoader(req.name());
                     if (loader1 != loader2 && !isAncestor(loader2, loader1) && !md.name().equals("javafx.swing")) {
                         throw new Error(loader1.getName() + "/" + md.name() +
                             " can't delegate to find classes from " +
                             loader2.getName() + "/" + req.name());
                     }
                 }));
    }   


> Has the module-loader-map.conf changed in your environment?

Nope.  And @dumasun also reproduced the issue for x86_64.  Perhaps she could provide more information.

Thanks,
Leslie Zhai

-------------

PR: https://git.openjdk.org/jdk/pull/10328