RFR: 8293910: tools/launcher/FXLauncherTest.java fail with jfx [v2]

[Alan Bateman]

On Sat, 17 Sep 2022 04:03:35 GMT, Leslie Zhai <lzhai 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="tools/launcher/FXLauncherTest.java"` failed:
>> 
>> 
>> ----------System.err:(11/697)----------
>> java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>>     at FXLauncherTest.main(FXLauncherTest.java:451)
>>     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)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> JavaTest Message: shutting down test
>> 
>> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK
>> 
>> 
>> Thanks,
>> Leslie Zhai
>
> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293910: Try --upgrade-module-path and --patch-module but still failed

I've created JDK-8294093 to track changing ReadSingleImportMetaData (in Modules.gmk) to ignore the mapping in build.properties. If nothing else, that will avoid surprises that will otherwise arise if you run jlink to create a run-time image that includes the javafx.* modules; when you run jlink then it does not map unknown modules to the boot or platform class loader so they will be mapped to the application class loader.

The other aspect to this is whether javafx.* modules should be upgradable. The build adds the imported modules PLATFORM_MODULES but not UPGRADEABLE_PLATFORM_MODULES so this means they will be treated as if they are strongly coupled with the platform/JDK modules and hashed, which probably isn't right here.

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

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