Library.isLoadable() failing unexpectedly

[openaudible]

Library.isLoadable() fails when SWT-OS or SWT-Arch manifest entries are missing, with error:

Libraries for platform win32 cannot be loaded because of incompatible environment

This breaks uber JARs (where build tools lose manifest entries during merge) and universal binaries (where a single manifest can't specify multiple architectures).

I am including a proposed a simple fix to clarify the error message and work under these conditions.

To Reproduce

Scenario 1: Uber JAR

1. Create Maven project with SWT dependency
2. Build with maven-assembly-plugin without preserving manifest entries:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-assembly-plugin</artifactId>
    <configuration>
        <descriptorRefs>
            <descriptorRef>jar-with-dependencies</descriptorRef>
        </descriptorRefs>
    </configuration>
</plugin>

3. Run the resulting JAR (java -jar xyz-jar-with-dependencies.jar)
4. Application exits with "incompatible environment" error

Scenario 2: Universal Binary

1. Create macOS universal binary by combining x86_64 and aarch64 libraries with lipo
2. Package with single manifest (can only specify one SWT-Arch value)
3. Run on the non-manifest architecture
4. Application exits with "incompatible environment" error

Expected behavior

The check should:

• Allow when manifest entries are missing (uber JAR or universal binary scenario)
• Fail when manifest entries are present but mismatched (actual wrong platform JAR)
• Provide clear diagnostic message explaining the mismatch

This distinguishes between acceptable scenarios (missing entries) and actual errors (wrong platform).

Environment

1. Platform:

   • All OS
   • Windows
   • Linux
   • macOS

2. Additional OS info: Affects all platforms equally

3. JRE/JDK version: All versions

Version since

PR #2054 and #2026 cc @HeikoKlare
Introduced in commit 360a270 (April 23, 2025) - likely Eclipse 4.33 or later

Workaround

For uber JARs: Configure build tool to preserve manifest entries:

<archive>
    <manifestEntries>
        <SWT-OS>win32</SWT-OS>
        <SWT-Arch>x86_64</SWT-Arch>
    </manifestEntries>
</archive>

For universal binaries: No workaround available (manifest can only contain single architecture)
I've been using universal binaries for Mac for a long time -- as the .classes are identical and it is pretty trivial to use lipo to merge aarch64 and intel.

Proposed Fix

Location: bundles/org.eclipse.swt/Eclipse SWT PI/common/org/eclipse/swt/internal/Library.java lines 214-222

Current code:

String manifestOS = attributes.getValue("SWT-OS");
String manifestArch = attributes.getValue("SWT-Arch");
if (arch.equals(manifestArch) && os.equals(manifestOS)) {
    return true;
}
return false;  // Fails for both missing AND mismatched

Proposed change:

String manifestOS = attributes.getValue("SWT-OS");
String manifestArch = attributes.getValue("SWT-Arch");

// Missing: allow (uber JAR or universal binary)
if (manifestOS == null || manifestArch == null) {
    return true;
}

// Present but mismatched: fail with clear diagnostic
if (!arch.equals(manifestArch) || !os.equals(manifestOS)) {
    System.err.println("SWT platform mismatch:");
    System.err.println("  Manifest: SWT-OS=" + manifestOS + ", SWT-Arch=" + manifestArch);
    System.err.println("  Runtime: os=" + os + ", arch=" + arch);
    return false;
}

return true;

This 5-line change:

• Fixes uber JAR and universal binary scenarios
• Still catches wrong platform JARs (e.g., Linux JAR on Windows)
• Provides clear diagnostics when actual mismatch detected
• Maintains security benefit of platform checking

Thank you SWT Team!

[akurtakov]

Such a change will allow trying to run a "uber" jar with SWT's Windows classes on Mac or Linux. It's definitely not a wanted case.

[laeubi]

Such a change will allow trying to run a "uber" jar with SWT's Windows classes on Mac or Linux. It's definitely not a wanted case.

"Allowing" is a bit to optimistic, it will then simply fail. For me it sounds valid to skip the check if manifest entries are missing as we can assume its the deliberate choice of the creator of that jar and should be aware of the consequences. At least it is not harmful for the common case at all.

Maybe as a middle ground we can print a warning that the check is not effective here.

[akurtakov]

I would request someone to try with the proposed patch running such a uber jar containing windows' swt being run on macos and vice-versa and show here what will users face.

[openaudible]

This proposed change partially reverts the functionality to how it has been working well for decades.

When you launch the wrong jar, the existing loadLibrary function gives a detailed error message about not being able to load the swt native libraries. This includes a full report, a list of the libraries that can't be loaded, and a helpful stack trace.

The new isLoadable check can return a false result and unclear error message.

Many developers such as myself are using install4j, which creates installers for the different architectures. It is non-trivial to download the .dmg or .rpm, or .exe and extract it onto the wrong platform and run it in a JRE (which is bundled into the app.).

I package with maven all dependencies so that I can include a simple debug.sh or debug.bat file that simply has a:
java -jar app_win64.jar One jar for the whole app.

Universal binaries are very nice to have, especially for Mac. The Intel version will run on the Apple Silicon, but will be much slower, or you'll need to instruct the user to download the apple silicon version. Or we'd need to write a custom class loader to choose the right jar. (The SWT jar files for apple silicon and apple intel are identical except for the manifest and the jnilib files, and it is trivial to use lipo to build a universal .jnilib. I'm sure there are plenty of Apple users who don't even know if they're running Intel or Aarch64.)

I don't like to criticize the work of volunteers, but this isLoadable breaks existing code, will return the wrong result when used with common maven build systems, and won't be compatible with universal binaries that might be shipped in the future.

I do really appreciate all the efforts of the SWT volunteers! Happy to provide any assistance reproducing this or answering questions.

[akurtakov]

Would you please provide the output requested in #2928 (comment) ?

[openaudible]

@akurtakov Here are two examples:

Attempting to run the gtk version from windows.

D:\openaudible\installers\opt\OpenAudible>java -jar openaudible_gtk_x86_64.jar
org.openaudible.desktop.swt.gui.GUI <init>
INFO: Starting OpenAudible build 4.6.9.4 for gtk swt 4963 jvm 25
org.openaudible.Directories load
INFO: Library path set to D:\oa_library\books
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::loadLibrary has been called by org.eclipse.swt.internal.Library in an unnamed module (file:/D:/openaudible/installers/opt/OpenAudible/openaudible_gtk_x86_64.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
        no swt-gtk-4963r5 in java.library.path: C:\Users\oa\.jdks\openjdk-25\bin
        no swt-gtk in java.library.path: C:\Users\oa\.jdks\openjdk-25\bin
		no swt in java.library.path: C:\Users\oa\.jdks\openjdk-25\bin
		Can't load library: C:\Users\oa\.swt\lib\win32\x86_64\swt-gtk-4963r5.dll
        Can't load library: C:\Users\oa\.swt\lib\win32\x86_64\swt-gtk.dll
        Can't load library: C:\Users\oa\.swt\lib\win32\x86_64\swt.dll

        at org.eclipse.swt.internal.Library.loadLibrary(Library.java:345)
        at org.eclipse.swt.internal.Library.loadLibrary(Library.java:254)
        at org.eclipse.swt.internal.C.<clinit>(C.java:19)
        at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:209)
        at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:155)
        at org.eclipse.swt.widgets.Display.<clinit>(Display.java:169)
        at org.openaudible.desktop.swt.manager.AppLoader.<init>(AppLoader.java:187)
        at org.openaudible.desktop.swt.manager.AppLoader.main(AppLoader.java:245)
        at org.openaudible.desktop.Application.main(Application.java:48)

Here I try to run the Mac universal version on windows:

D:\openaudible\installers\OpenAudible.app\Contents\Resources\app>java -jar openaudible_mac_universal.jar
org.openaudible.desktop.swt.gui.GUI <init>
INFO: Starting OpenAudible build 4.6.9.4 for cocoa swt 4963 jvm 25
org.openaudible.Directories load
INFO: Library path set to D:\oa_library\books
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::loadLibrary has been called by org.eclipse.swt.internal.Library in an unnamed module (file:/D:/openaudible/installers/OpenAudible.app/Contents/Resources/app/openaudible_mac_universal.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
        no swt-cocoa-4963r5 in java.library.path: C:\Users\oa\.jdks\openjdk-25\bin
		no swt-cocoa in java.library.path: C:\Users\oa\.jdks\openjdk-25\bin
		no swt in java.library.path: C:\Users\oa\.jdks\openjdk-25\bin
		Can't load library: C:\Users\oa\.swt\lib\win32\x86_64\swt-cocoa-4963r5.dll
        Can't load library: C:\Users\oa\.swt\lib\win32\x86_64\swt-cocoa.dll
        Can't load library: C:\Users\oa\.swt\lib\win32\x86_64\swt.dll

        at org.eclipse.swt.internal.Library.loadLibrary(Library.java:345)
        at org.eclipse.swt.internal.Library.loadLibrary(Library.java:254)
        at org.eclipse.swt.internal.C.<clinit>(C.java:19)
        at org.eclipse.swt.widgets.Display.<clinit>(Display.java:110)
        at org.openaudible.desktop.swt.manager.AppLoader.<init>(AppLoader.java:187)
        at org.openaudible.desktop.swt.manager.AppLoader.main(AppLoader.java:245)
        at org.openaudible.desktop.Application.main(Application.java:48)

I can provide examples on Mac or Linux trying to launch the wrong code.

All downloads (using SWT 3.124.200, without the new isLoadable) are available https://openaudible.org/download so feel free to try for yourself - each download has a debug_* script that demonstrates the java -jar command.

[HeikoKlare]

The issue was introduced by Library.isLoadable() now always being executed on SWT initialization. Library.isLoadable() would have failed before in the same if it was ever executed.
I have no strong opinion on how to solve this issue. I see two simple options that are in my opinion both acceptable as they almost restore what has been there before:

1. Make Library.isLoadable() ignore a missing manifest, as already proposed above
2. Add a Library.isLoadable(ignoreMissingManifest) method and make the SWT library initializers call that method with false, such that a missing manifest will not make library initialization fail but still keep the pre-existing behavior of Library.isLoadable().

I would personally prefer the second option to stay as much compatible as possible. But one might also argue that the behavior of Library.isLoadable() is (and always was) unexpected for Uber JARs and universal binaries as indicated by the issue title/description.