Fix Eclipse Failed to Load JNI Shared Library (JDK)

This page explains how Eclipse starts a JVM, why loading jvm.dll can fail even when the file exists, and how to diagnose architecture, JDK-path, and configuration problems without immediately switching to 32-bit software.

Eclipse is a native desktop application that must start a Java Virtual Machine (JVM) before the Java-based parts of the IDE can run. On Windows, the JVM is implemented by a dynamic-link library named jvm.dll.

The message Failed to load the JNI shared library means Eclipse's launcher could not load the JVM library it was told to use. JNI stands for Java Native Interface: it is the bridge that allows native programs, such as the Eclipse launcher, to interact with the JVM.

A file existing on disk is necessary, but it is not sufficient. Windows can refuse to load a DLL when, for example:

• The Eclipse launcher and jvm.dll have different architectures, such as 32-bit versus 64-bit.
• Eclipse is configured to use an outdated, incomplete, or incorrect Java installation.
• The configured -vm path points to the wrong jvm.dll location.
• A Java installation is damaged or its required DLL dependencies cannot be found.
• Environment variables or launch configuration select a different Java installation than expected.

The core rule is: the native Eclipse launcher and the JVM library it loads must have compatible architecture and come from a valid Java installation. A 64-bit version of Windows can run both 32-bit and 64-bit programs, but a 64-bit native process cannot load a 32-bit DLL, and a 32-bit native process cannot load a 64-bit DLL.

Think of Eclipse as a 64-bit electrical appliance and jvm.dll as a power adapter. The adapter may be sitting on the desk, but Eclipse can use it only if its connector matches.

A 64-bit Eclipse launcher requires a 64-bit JVM library. A 32-bit Eclipse launcher requires a 32-bit JVM library. A 64-bit version of Windows is like a building with outlets for both appliance types, but it does not make mismatched plugs fit together.

The eclipse.ini file is Eclipse's instruction card. If that card tells Eclipse to use an old or wrong adapter, Eclipse may ignore the JDK you intended to use and fail before the IDE opens.

On Windows, Eclipse can be directed to a particular JVM by adding a -vm entry to eclipse.ini, usually located beside eclipse.exe.

-vm
C:\Program Files\Java\jdk-21\bin\server\jvm.dll

Important rules:

• Put -vm before -vmargs in eclipse.ini.
• Put the option and its path on separate lines.
• Point to the JVM library file, not merely the JDK directory.
• Use a JDK whose architecture matches eclipse.exe.

A simplified configuration might look like this:

-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200000.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200000
-vm
C:\Program Files\Java\jdk-21\bin\server\jvm.dll
-vmargs
-Xms256m
-Xmx2048m

The exact plugin names and versions vary by Eclipse release. The relevant part is the -vm setting.

On many modern 64-bit JDK installations, the JVM library is commonly under bin\server\jvm.dll. An error mentioning bin\client\jvm.dll can be a clue that Eclipse is using an older configuration or a Java installation layout that is not the one you expected. Do not assume every JDK uses the same directory layout; verify the actual location in the JDK you installed.

Consider this eclipse.ini fragment:

-vm
C:\JDK\bin\client\jvm.dll
-vmargs
-Xmx1024m

When Eclipse starts:

1. Windows starts the native eclipse.exe launcher.
2. The launcher reads eclipse.ini.
3. It sees -vm and chooses C:\JDK\bin\client\jvm.dll instead of automatically searching for Java.
4. The launcher asks Windows to load that DLL.
5. Windows checks whether the DLL can be loaded into the Eclipse process. This includes checking native architecture and required dependencies.
6. If the DLL is incompatible, invalid, or cannot load its dependencies, Eclipse displays the JNI shared-library error and exits.

To diagnose the selected Java installation, run these commands in Command Prompt:

where java
java -version
echo %JAVA_HOME%

where java shows which java.exe files are found through PATH. java -version reports the JVM used by that command. These commands help identify conflicting installations, but Eclipse may still use a different JVM when eclipse.ini contains -vm.

A practical troubleshooting sequence is:

1. Open eclipse.ini and check whether it contains -vm.
2. If it does, verify that the path exists and points to the intended JDK's jvm.dll.
3. Verify that the Eclipse download and that JDK use the same architecture.
4. Correct the path, or remove an obsolete -vm setting so Eclipse can use its intended runtime-discovery behavior.
5. If the JDK is damaged or unsupported by that Eclipse release, install a supported JDK and point Eclipse to it explicitly.

This issue is an example of a broader native-library compatibility problem.

• IDE startup: Eclipse, Android development tools, and other Java tools may need to load a JVM before their Java code can run.
• Java server integrations: Application servers can fail at startup if a service wrapper is 64-bit but is configured with a 32-bit JVM library.
• JNI-based Java applications: A Java application that loads a native database, image-processing, or hardware-driver DLL must use a library compiled for the JVM's architecture.
• Build agents: CI machines often have several JDKs installed. A build tool can select the wrong JDK through JAVA_HOME, PATH, or a tool-specific configuration.
• Desktop installers: An installer may create a shortcut or configuration file that continues pointing to a removed Java version after an upgrade.

Developers and operations teams usually avoid relying on whichever Java installation happens to appear first in PATH.

Common patterns include:

• Pin the JDK path: Configure a tool, service, or build system to use one known JDK version.
• Validate at startup: Scripts check that Java exists and print java -version before running the main program.
• Use an explicit architecture policy: Teams standardize on 64-bit tools and JDKs for a development environment, rather than mixing installers.
• Keep tool-specific configuration local: Eclipse's eclipse.ini controls Eclipse directly; changing global variables is not always necessary.
• Avoid stale paths after upgrades: When replacing a JDK, update configuration files, service definitions, and CI settings that reference the old directory.

For example, a Windows launch script can fail early with a useful message:

@echo off
if not exist "%JAVA_HOME%\bin\java.exe" (
  echo JAVA_HOME does not point to a valid JDK.
  exit /b 1
)

"%JAVA_HOME%\bin\java.exe" -version

This does not configure Eclipse itself, but it demonstrates the useful real-world practice of validating an external runtime before depending on it.

Assuming that an existing DLL must be loadable

This reasoning is incomplete:

C:\JDK\bin\client\jvm.dll exists, so Eclipse should start.

The DLL can exist while still being the wrong architecture, corrupt, missing dependencies, or selected from the wrong Java installation.

Matching Windows architecture but not application architecture

A 64-bit Windows installation can run both kinds of applications. It does not allow this combination:

64-bit eclipse.exe + 32-bit jvm.dll

Match Eclipse and the JDK to each other, not just to Windows.

Editing eclipse.ini with -vm after -vmargs

This is a common incorrect layout:

-vmargs
-Xmx1024m
-vm
C:\Program Files\Java\jdk-21\bin\server\jvm.dll

Arguments after -vmargs are passed to the JVM rather than interpreted as launcher options. Put -vm before -vmargs.

Pointing -vm at a folder or java.exe

When using this form of configuration, use the actual JVM library path required by the launcher:

-vm
C:\Program Files\Java\jdk-21\bin\server\jvm.dll

Do not use a directory-only path such as C:\Program Files\Java\jdk-21.

Changing only PATH

Updating PATH can affect java in a terminal, but it may not fix Eclipse if Eclipse has an explicit -vm entry. Check the tool's own configuration first.

Installing a 32-bit JDK as a blind fix

A 32-bit JDK is appropriate only when the Eclipse launcher is also 32-bit or when a specific legacy dependency requires it. For a 64-bit Eclipse installation, first fix the selected 64-bit JDK path and configuration.

PATH helps the command line locate executables. JAVA_HOME identifies a Java installation for tools that honor it. An explicit -vm entry is usually the clearest way to tell Eclipse which JVM to load.

• jvm.dll is the native JVM library on Windows.
• Eclipse must load a JVM before the IDE can run.
• The Eclipse launcher and jvm.dll must have the same architecture.
• A 64-bit Windows system can run 32-bit and 64-bit apps, but one process cannot load a DLL of the other architecture.
• Check eclipse.ini for:

-vm
C:\path\to\jdk\bin\server\jvm.dll

• Put -vm before -vmargs.
• Verify the chosen path points to the intended JDK, not an old JRE or removed installation.
• Use these diagnostics:

where java
java -version
echo %JAVA_HOME%

• Do not use a 32-bit JDK with 64-bit Eclipse merely because Windows is 64-bit.
• If the selected JDK cannot load, reinstall a supported JDK and update the explicit path.

What does “Failed to load the JNI shared library” mean in Eclipse?

It means the Eclipse launcher could not load the JVM's native library, jvm.dll, so Eclipse cannot start its Java runtime.

Why does Eclipse report this error when jvm.dll exists?

Existence only proves the path contains a file. The file may have the wrong architecture, be damaged, lack dependencies, or belong to the wrong Java installation.

Does 64-bit Windows require 64-bit Eclipse and Java?

No. Windows can run either architecture. However, Eclipse and the JVM it loads must match each other: 64-bit with 64-bit, or 32-bit with 32-bit.

Where should I configure the JDK used by Eclipse?

Check the eclipse.ini file next to eclipse.exe. An explicit -vm entry can specify the JVM library Eclipse should load.

Should -vm point to java.exe or jvm.dll?

For the eclipse.ini pattern shown here, point it to the JVM library file, such as ...\bin\server\jvm.dll, following the layout present in your JDK.

Why is Eclipse trying to use bin\client\jvm.dll?

That path may come from an old Eclipse configuration, an older Java layout, or a manually configured JVM path. Inspect eclipse.ini and any launch configuration that references it.

Will changing JAVA_HOME fix the error?

It can help if Eclipse is discovering Java from the environment. It will not override an explicit and incorrect -vm path in eclipse.ini.

When should I install 32-bit Java and Eclipse?

Use them together only if you intentionally need a 32-bit Eclipse environment or a legacy 32-bit native dependency. Do not mix them with a 64-bit JVM or launcher.

• Java Virtual Machine (JVM) — The runtime Eclipse needs to execute Java code.
• Java Native Interface (JNI) — The mechanism involved when Java and native libraries interact.
• Dynamic-link libraries (DLLs) — Windows native libraries such as jvm.dll.
• 32-bit and 64-bit architecture — Explains why native executables and DLLs must be compatible.
• Environment variables — PATH and JAVA_HOME can influence runtime discovery.
• Java installation paths — Helps distinguish a JDK, JRE, and stale installation reference.
• Application configuration files — eclipse.ini is an example of configuring a program's startup behavior.
• Dependency loading — Covers why a library can exist but still fail to load.