When I try opening Eclipse, a pop-up dialog states:
Failed to load the JNI shared library "C:/JDK/bin/client/jvm.dll"`.
Following this, Eclipse force closes.
Here's a few points I'd like to make:
- I checked to see if anything exists at that path. It does exist.
- My Eclipse and Java SE Development Kit are both 64-bit. I checked my system, and it can handle 64-bit.
- I've searched for this problem on Google and on Stack Overflow, and the only answer I found was to download the 32-bit versions of JDK and Eclipse.
Downloading the 32-bit versions is something I only want to do as a very last resort.
What would be suggested to solve this issue?
Yes, just make sure your versions of Eclipse and JDK are both 64-bit. Just to make sure everything is correct uninstalled JDK and install it in Program Files and not in Program Files (x86). At least that resolved my problem.
If you use whole 64-bit trio and it still doesn't work (I've come to this problem while launching Android Monitor in Intellij Idea), probably wrong jvm.dll is being used opposed to what your java expects. Just follow these steps:
Find the jvm.dll in your JRE directory:
C:\Program Files\Java\jre7\server\bin\jvm.dll
Find the jvm.dll in your JDK directory:
c:\Program Files\Java\jdk1.7.0_xx\jre\bin\server\
Copy the
jvm.dll
from JRE drectory into your JDK directory and overwrite the jvm.dll in JDK.Don't forget to make a backup, just in case. No need to install or uninstall anything related to Java.
I had same problem
I resolved it by installing 64 bit JVM from
http://www.java.com/en/download/manual.jsp
The answers above me got me tempted so much, that I decided to dry run all the possible combinations with OS, Eclipse and JVM trio. Anyway, whoever is digging down and reading my post, check the following as a hot spot (I am Windows 7 user).
You understand Program Files and Program File (x86) are two different folders... x86 stands for the 32-bit version of programs and the former is the 64-bit version.
If you have multiple versions of Java installed with different bitness and release versions, which is bound to happen with so many open source IDEs, managers, administrative consoles, the best option is to set the VM argument directly in the
eclipse.ini
file. If you don't, Eclipse will go crazy and try searching itself which is not good.Working pairings of OS, JDK and Eclipse:
I had several JDKs and JREs installed.
Each of them had their own entry in the PATH variable, all was working more or less.
Judging from the PATH variables, some installations were completely useless, since they were never used. Of course, the "inactive" Javas could be referenced manually from within Eclipse if I needed, but I never did that, so I really did not need them. (At least I thought so at that time...)
I cleaned up the mess, deinstalled all current Java's, installed only JDK + JRE 1.7 64-bit.
One of the Eclipse 'installations' failed afterwards with the
Failed to Load the JNI shared Library
and a given path relative to the fresh installed JDK where it thought thejvm.dll
to be.The failing Eclipse was the only one of all my IDEs that was still a 32-bit version on my otherwise all-64-bit setup.
Adding VM arguments, like so often mentioned, in the
eclipse.ini
was no use in my case (because I had only the wrong JDK/JRE to relate to.)I was also unable to find out how to check if this Eclipse was a 32-bit or 64-bit version (I could not look it up in the Task Manager, since this Eclipse 'installation' would not start up. And since it had been a while since I had set it up, I could not remember its version either.)
In case you use a newer JDK and a older JRE you might be in for trouble, too, but then it is more likely a
java.lang.UnsupportedClassVersionError
appears, IIRC.Make sure your eclipse.ini file includes the following lines.
My eclipse.ini for example:
Use OS and Eclipse both 64 bit or both 32 bit keep same and config eclipse.ini.
Your eclipse.ini file can be found in your eclipse folder.