GraalVM 22+ produces jdk_library artifacts for windows swing app

[theotherp]

Describe the issue
I've updated my build script to use GraalVMgraalvm-community-openjdk-22+36.1. While previously graalvm-community-openjdk-17.0.9+9.1 (and graalvm-community-openjdk-21+35.1) produced a single exe file now also DLL files are created as artifacts.

Steps to reproduce the issue
Clone https://github.com/theotherp/nzbhydra2 and run

1. mvn -q -pl org.nzbhydra:nzbhydra2,org.nzbhydra:shared,org.nzbhydra:mapping,org.nzbhydra:assertions,org.nzbhydra:core clean install -B -T 1C -DskipTests=true
2. buildCore.cmd (you need to adapt the path to graalvm).

Describe GraalVM and your environment:

• GraalVM version: 22+36.1
• JDK major version: 21
• OS: Windows 10
• Architecture: AMD 64

More details
Excerpt from build:

Java version: 22+36, vendor version: GraalVM CE 22+36.1
 Graal compiler: optimization level: 2, target machine: compatibility
 C compiler: cl.exe (microsoft, x64, 19.34.31937)
 Garbage collector: Serial GC (max heap size: 80% of RAM)
 3 user-specific feature(s):
 - com.oracle.svm.thirdparty.gson.GsonFeature
 - org.eclipse.angus.activation.nativeimage.AngusActivationFeature
 - org.springframework.aot.nativex.feature.PreComputeFieldFeature
------------------------------------------------------------------------------------------------------------------------
 5 experimental option(s) unlocked:
 - '-H:DeadlockWatchdogInterval' (origin(s): command line)
 - '-H:-DeadlockWatchdogExitOnTimeout' (origin(s): command line)
 - '-H:+StaticExecutableWithDynamicLibC' (origin(s): command line)
 - '-H:ResourceConfigurationResources':
...
 - Produced artifacts:                                                                      
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\awt.dll (jdk_library)             
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\core.exe (executable)             
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\fontmanager.dll (jdk_library)     
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\freetype.dll (jdk_library)        
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\jaas.dll (jdk_library)            
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\java.dll (jdk_library_shim)       
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\javaaccessbridge.dll (jdk_library)
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\javajpeg.dll (jdk_library)        
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\jawt.dll (jdk_library)            
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\jsound.dll (jdk_library)          
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\jvm.dll (jdk_library_shim)        
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\lcms.dll (jdk_library)            
 C:\Users\theotherp\IdeaProjects\nzbhydra2\core\target\w2k_lsa_auth.dll (jdk_library)    

[fniephaus]

From the docs on the build artifacts section:

For applications using AWT, for example, the build process will also output libraries from the JDK and shims to provide compatible AWT support. These libraries need to be copied and distributed together with the native binary.

AWT libraries can no longer be statically linked so this is expected behavior. For more info, see #4921.

[theotherp]

Alright. I looked on the project website https://www.graalvm.org/release-notes/JDK_22/ and didn't find anything there (a search function would be helpful).

I can live with that, was just surprised as I didn't see this change anywhere in the release notes.

[fniephaus]

@theotherp it's been like this on Linux and Windows for some time now. The release notes of GraalVM for JDK 17, for example, mention the switch to dynamic linking on Linux.