roosevelt roosevelt - 5 months ago 20x
Java Question

Cannot load 64-bit SWT libraries on 32-bit JVM (even though I downloaded 32-bit SWT)

I am currently developing on a 64-bit Windows 7 machine. I have JRE7 64-bit and JRE7 32-bit installed on my machine. I am using Eclipse 64-bit version and configured Window - Preferences - Java - Installed JREs to use JRE7 32-bit to be my default JRE to test against. Also installed the 32-bit JDK and currently using that to test against.

I double checked and made sure I am indeed using SWT 32-bit Windows but still during compilation it throws me the "Cannot load 64-bit SWT libraries on 32-bit JVM" error.

The error clearly indicates that Eclipse is indeed using JDK7-32 Bit but for some reason the SWT Libraries ( is not fully 32-bit o.O...

Any ideas? Any workarounds?

FYI, switching the JRE to 64-bit compiles the program just fine but I want my application to work on both 32-bit and 64-bit.

Here is the full exception:

Exception in thread "main" java.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM
at org.eclipse.swt.internal.Library.loadLibrary(
at org.eclipse.swt.internal.Library.loadLibrary(
at org.eclipse.swt.internal.C.<clinit>(
at org.eclipse.swt.widgets.Widget.<clinit>(
at Test.Application.<init>(
at Test.Application.main(


SWT uses plugin fragments to control this - there is a 32-bit fragment and a 64-bit fragment (as well as fragments for Mac, Linux, etc). Make sure your launch configuration is set to use the proper fragment depending on which JVM you're running it on.

As a note, just including "both" plugin fragments will not work, as then they will both attempt to load and cause problems.

Also, this related question may be useful.

Another idea would be to dive into the loadLibrary function - from what I remember of how that works, it looks for a cached version of the SWT dll from a temp location somewhere, and so it might be using a cached 64-bit dll instead of properly unpacking the 32-bit one from the jar. In that case, deleting the cached one may fix the issue.

The easiest solution, though, may be just to have two separate instances of Eclipse: one setup to run 32-bit, one setup to run 64-bit. This way you don't have to worry about toggling back and forth, or futz around with configurations as much.