I sometimes get the same error when building the latest jfx master
branch, so I don't think this is limited to jfx17u. Must be some kind of
oversight in the buildscript.
I can reproduce it like this: Clone the jfx repo into new directory. Run
sh gradlew :sdk in it. The first time you run this, it will throw this error
On 14/04/2026 19:58, Thorsten Fischer wrote:
Hello all,
I ran into an issue while building OpenJFX 17u on Linux. The build
failed for me with:
"Entry swt-debug.jar is a duplicate but no duplicate handling strategy
has been set"
I usually work with Eclipse, but I switched to VS Code for my current
task. It appears that in my local setup, VS Code / Java / Gradle
tooling pulled not only the SWT binary jar into the Gradle cache, but
also the corresponding '-javadoc.jar'
(org.eclipse.swt.gtk.linux.x86_64_3.105.3.v20170228-0512-.jar and
org.eclipse.swt.gtk.linux.x86_64_3.105.3.v20170228-0512--javadoc.jar).
Both files matched the include pattern from the Gradle build file and
were renamed to the same target name (swt-debug.jar), which then
caused the duplicate entry failure after a clean build.
I analyzed this with ChatGPT/Codex, and it suggested the change below
to the Gradle build file. Even though the problem was likely due to my
local tooling / IDE setup rather than the normal OpenJFX build, this
change still seems more robust than the current Gradle logic, since it
selects the actual SWT binary jar directly instead of matching any
'*swt*.jar' file in the cache directory.
Maybe someone with more expertise with the build-system can comment on
whether this is a reasonable fix.
Note: this change is for the 17u branch, but master still looks
similar:
https://github.com/openjdk/jfx/blob/master/build.gradle#L3168-L3170
diff --git a/build.gradle b/build.gradle
index 13d6e0129c..f9cd3057d9 100644
--- a/build.gradle
+++ b/build.gradle
@@ -2694,17 +2694,19 @@ project(":swt") {
// Skip copy if file is present.
if (swtLib.exists()) return;
- for (File f : configurations.compileClasspath.files) {
- // Have to rename the swt jar because it is some
platform specific name but
- // for the sake of the IDEs we need to have a single
stable name that works
- // on every platform
- copy {
- into libsDir
- from f.getParentFile()
- include "**/*swt*.jar"
- includeEmptyDirs = false
- rename ".*swt.*jar", "swt-debug\\.jar"
- }
+ File swtBinary =
configurations.compileClasspath.files.find {
+ it.name == "${SWT_FILE_NAME}-.jar"
+ }
+ if (swtBinary == null) {
+ throw new GradleException("Unable to locate SWT
binary jar ${SWT_FILE_NAME}-.jar on the compile classpath")
+ }
+
+ // Copy exactly the SWT binary jar. Its cache directory
can also contain
+ // javadocs, which would otherwise be renamed to the same
target name.
+ copy {
+ into libsDir
+ from swtBinary
+ rename { "swt-debug.jar" }
}
}
}
Greetings, Thorsten
