Windows ignores JAVA_HOME: how to set JDK as default?
WindowsJavaWindows Problem Overview
How do I persuade Windows to use the JDK instead of a JRE?
This question has been asked before, here and elsewhere:
The trouble is that Windows ignores JAVA_HOME
and it also ignores the fact that I made the JDK bin directory the first entry in the path.
When I run java -version
from the command line, instead of invoking my JDK 1.6 installation, it runs the 1.7 JRE.
My guess is that this is a problem specific to 1.7, and Windows 7 is doing something it shouldn't with the registry.
Any ideas on how to fix this?
Edit: Oops. I wrote "first entry in the classpath" above, when I meant "path". Sorry.
Windows Solutions
Solution 1 - Windows
On Windows, the java
executable uses the Windows Registry to locate the default version of Java to run.
The copy of java.exe
to run is found by using the PATH
environment variable. Unless you take steps to change this, by default a copy will be found in the Windows directory. Since this copy isn't in a Java runtime directory, it locates one by looking at the registry.
So, you either need to modify the registry, or put the version of Java you want before the Windows directory in your PATH
.
Solution 2 - Windows
In Windows 8, you may want to remove
C:\ProgramData\Oracle\Java\javapath
directory.
from path
It solved my issue.
Solution 3 - Windows
I have this issue too. I am running 1.6 but want to build the code I'm working on with 1.5. I've changed the JAVA_HOME
and PATH
(both user and system) to no avail.
The answer is that the installer for 1.6 dropped java.exe
, javaw.exe
, and javaws.exe
into my Windows\System32
folder (Windows 7).
I solved it by renaming those files to java_wrong.exe
, javaw_wrong.exe
, and javaws_wrong.exe
. Only after doing that does it pick up the correct version of java as defined in JAVA_HOME
and PATH
. I renamed the files thusly because that deleted them in an easily reversible manner.
Hope this helps!
Solution 4 - Windows
Windows doesn't ignore anything. This is an issue with your setup; Windows just uses what you provide. It has no special knowledge of JAVA_HOME
.
CLASSPATH
has nothing to do with Windows, either. To Windows it's only an environmental variable that gets expanded to a folder location.
Check your %PATH%
environmental variable. It's what's making Windows find one before the other. The path (as the post you linked to said) should point to %JAVA_HOME%\bin;<remainder of path>
. Again, the post you linked to gave you a way to set this using a batch file.
(For others who might not know this: The easiest way to inspect the %PATH% is to open a command prompt and type echo %PATH%
. You can also get there by right-clicking on Computer
in the right pane of the Start Menu and choosing Properties
, then Advanced System Settings
, and the tne Environmental Variables
button.)
Solution 5 - Windows
I had the same issue. I have a bunch of Java versions installed and for some reason Java 1.7 was being used instead of Java 1.6, even though I specified in the path to use 1.6 (C:\jdk1.6.0_45_32\bin).
I had to move the path of the JDK I wanted to use (1.6) to be the first entry in the PATH environment variable to make sure Windows uses 1.6 instead of 1.7.
So, for example, the PATH environment variable before was:
C:\Program Files (x86);...<other entries>;C:\dev\ant181\bin;C:\jdk1.6.0_45_32\bin
and after I moved the jdk to be first, it worked:
C:\jdk1.6.0_45_32\bin;C:\Program Files (x86);...<other entries>;C:\dev\ant181\bin
I guess the Windows installer of Java 1.7 installed it to some other directory already in the PATH, thus getting used first instead of the specified custom PATH entry C:\jdk1.6.0_45_32\bin;
Solution 6 - Windows
Suppose you have install JDK 10 after JDK 8 and in the system environment variable set path like "C:\ProgramData\Oracle\Java\javapath" then Java version control by this path. it will ignore JAVA_HOME even jdk 1.8 path set here So remove "C:\ProgramData\Oracle\Java\javapath" in path to get effect of JAVA_HOME path
Solution 7 - Windows
For my Case in 'Path'
variable there was a parameter added like 'C:\ProgramData\Oracle\Java\javapath;
'.
This location was having java.exe
, javaw.exe
and javaws.exe
from java 8 which is newly installed via jdk.exe
from Oracle.
I've removed this text from Path where my Path already having %JAVA_HOME%\bin
with it.
Now, the variable 'JAVA_HOME'
is controlling my Java version which is I wanted.
Solution 8 - Windows
Set Path environment variable to your desired jdk/bin directory
Solution 9 - Windows
I had Java 7 and 8 installed and I want to redirect to java 7 but the java version in my cmd prompt window shows Java 8.
Added Java 7 bin directory path (C:\Program Files\Java\jdk1.7.0_10\bin) to PATH variable at the end, but did not work out and shows Java 8. So I changed the Java 7 path to the starting of the path value and it worked.
Opened a new cmd prompt window and checked my java version and now it shows Java 7
Solution 10 - Windows
In my case I had Java 7 and 8 (both x64) installed and I want to redirect to java 7 but everything is set to use Java 8. Java uses the PATH environment variable:
> C:\ProgramData\Oracle\Java\javapath
as the first option to look for its folder runtime (is a hidden folder). This path contains 3 symlinks that can't be edited.
In my pc, the PATH environment variable looks like this:
> C:\ProgramData\Oracle\Java\javapath;C:\Windows\System32;C:\Program > Files\Java\jdk1.7.0_21\bin;
In my case, It should look like this:
> C:\Windows\System32;C:\Program Files\Java\jdk1.7.0_21\bin;
I had to cut and paste the symlinks to somewhere else so java can't find them, and I can restore them later.
After setting the JAVA_HOME and JRE_HOME environment variables to the desired java folders' runtimes (in my case it is Java 7), the command java -version
should show your desired java runtime. I remark there's no need to mess with the registry.
Tested on Win7 x64.
Solution 11 - Windows
This issue is probably because of the earlier versions of Java installed in your System. First check your Environment Variables Carefully and remove all the Environment Variables related to the previous versions of JAVA and replace those paths to
C:\Program Files\Java\<your new jdk version>\bin
Solution 12 - Windows
There's an additional factor here; in addition to the java executables that the java installation puts wherever you ask it to put them, on windows, the java installer also puts copies of some of those executables in your windows system32 directory, so you will likely be using which every java executable was installed most recently.
Solution 13 - Windows
Just in case if you are using .BAT file as Windows Service, I would suggest to uninstall the Windows service and reinstall it again after changing the %JAVA_HOME% to point to the right Java version..
Solution 14 - Windows
After struggling with this issue for some time and researching about it, I finally managed to solve it following these steps:
- install jdk version 12
- Create new variable in systems variable
- Name it as JAVA_HOME and give jdk installation path
- add this variable in path and move it to top.
- go to C:\Program Files (86)\Common Files\Oracle\Java\javapath and replace java.exe and javaw.exe with the corresponding files with the same names from the pathtojavajdk/bin folder
Finally, I checked the default version of java in cmd with "java -version" and it worked!
Solution 15 - Windows
I had the same problem, in user environment variable settings I was having JAVA_HOME and PATH configured properly but it didn't work. As I update my system environment variables then it started to work.
Solution 16 - Windows
I was facing the same issue. I had a java version of 8.11. I had these two in my path: C:\Program Files\Java\jdk1.8.0_51\bin
and C:\ProgramData\Oracle\Java\javapath
What I did is that I had changed the jdk to %JAVA_HOME%\bin
like this and renamed the directory (C:\ProgramData\Oracle\Java\javapath
) of javapath
to javapath1
and it resolved my problem.
Solution 17 - Windows
Delete C:\ProgramData\Oracle\Java\javapath from Path in system variables & add your custom value for JAVA_HOME variable for User variables. This will work in Windows 10.