Guideline to run on windows

[koppor]

When running in on Windows 10 (both cygwin and cmd), I get Error initializing QuantumRenderer: no suitable pipeline found

koppor@DESKTOP-KAK953S MINGW64 /c/git-repositories/jabref-all/java-module-system (main)
$ ./gradlew run
Starting a Gradle Daemon, 2 busy Daemons could not be reused, use --status for details
Calculating task graph as no cached configuration is available for tasks: run
Kotlin does not yet support 23 JDK target, falling back to Kotlin JVM_22 JVM target

> Task :plugins:compileKotlin
Kotlin does not yet support 23 JDK target, falling back to Kotlin JVM_22 JVM target
w: Inconsistent JVM-target compatibility detected for tasks 'compileJava' (23) and 'compileKotlin' (22).
This will become an error in Gradle 8.0.
Consider using JVM Toolchain: https://kotl.in/gradle/jvm/toolchain
Learn more about JVM-target validation: https://kotl.in/gradle/jvm/target-validation


> Task :app:run FAILED
Graphics Device initialization failed for :  d3d, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
        at javafx.graphics@21.0.2/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:283)
        at javafx.graphics@21.0.2/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:253)
        at javafx.graphics@21.0.2/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:263)
        at javafx.graphics@21.0.2/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:290)
        at javafx.graphics@21.0.2/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:162)
        at javafx.graphics@21.0.2/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:651)
        at javafx.graphics@21.0.2/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
        at javafx.graphics@21.0.2/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:364)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1149)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
        at javafx.graphics@21.0.2/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:95)
        at javafx.graphics@21.0.2/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125)
        at java.base/java.lang.Thread.run(Thread.java:1583)
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1149)
Caused by: java.lang.RuntimeException: No toolkit found
        at javafx.graphics@21.0.2/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:275)
        at javafx.graphics@21.0.2/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:290)
        at javafx.graphics@21.0.2/com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:162)
        at javafx.graphics@21.0.2/com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:651)
        at javafx.graphics@21.0.2/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:409)
        at javafx.graphics@21.0.2/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:364)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        ... 2 more

---

Cannot be tested with test yet:

C:\git-repositories\jabref-all\java-module-system>gradlew test
Calculating task graph as no cached configuration is available for tasks: test
Kotlin does not yet support 23 JDK target, falling back to Kotlin JVM_22 JVM target

> Task :plugins:compileKotlin FROM-CACHE
Kotlin does not yet support 23 JDK target, falling back to Kotlin JVM_22 JVM target

BUILD SUCCESSFUL in 24s
18 actionable tasks: 5 executed, 2 from cache, 11 up-to-date

Publishing build scan...
https://gradle.com/s/r7h7pus75eqnu

Configuration cache entry stored.

[koppor]

./gradlew runWindows-2022 works. I find this strange, because "normally", run should suffice, shouldn't it?

[jjohannes]

Thanks for the feedback @koppor - that is the correct analysis. It behaves like this, because the java-module-packaging plugin does not do detection of the current OS to make a selection. This is a conscious decision, but improvements can certainly be made. As you say, you would have expected run to just work™.

The goal is that the environment you run the build on does not influence the result of the build. So that builds are reproducible no matter on which machine they run. Hence, the plugin provides separate tasks for each target that is configured. In this case, for example:

assembleMacos-13 - Builds this project for macos-13
assembleMacos-14 - Builds this project for macos-14
assembleUbuntu-22.04 - Builds this project for ubuntu-22.04
assembleWindows-2022 - Builds this project for windows-2022

It makes much sense for assemble (IMO), because they really produce different artifacts. This way, it is clear which task produces what and you can even create a build that "runs" all the tasks and creates all results if you involve a remote build cache where the results are uploaded from different machines.

Still, for the "standard tasks" (such as run) that need to make some decission, you need to make a selection. Right now, you configure that explicitly. In this repository it is set to macos-14 (hence it fails on windows).

javaModulePackaging {
  primaryTarget(target("macos-14"))
}

This configuration is also used for the compile task, for which the selection does not really matter, as it does not care about the native aspects of the Jars. Still, in the spirit of reproducibility, I like the idea that it always uses the same Jars at compilation time independent of where the build runs.

---

I think the plugin could reconfigure the run task only to use whatever fits the current system. This will not break the idea of a reproducible build, as run is only for local testing/running. It has no outputs / produces no build results.
I created and issue for that: gradlex-org/java-module-packaging#51