I am trying to change between Java7 and Java 8 environments. I created the following new environment variables:
JAVA7_HOME - java 7 location
JAVA8_HOME - java 8 location
JAVA_HOME
I then set JAVA_HOME to be %JAVA8_HOME% or %JAVA7_HOME%. In path I have
%JAVA_HOME%\bin;REST OF PATH
It seems no matter what I set JAVA_HOME to it will not change the outcome of java -version, even for new sessions.
How can we have two separate java environments while easily changing between them? I've tried setting everything to the correct paths, that includes:
HKEY_CURRENT_USER\Environment JAVA_HOME
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment CurrentVersion
and even changing symlinks to point to the version we want. We've create batch scripts to do it all, we've create powershell/,net to do it and then broadcast, tried setting it all and restarting explorer.. It seems impossible to switch between 7 and 8.
Does anyone have an idea how to resolve this?
The basic problem is that changing environment variables via commandline is not permanent for some reason. You'll have to set the new value via the UI.
I used to do the following:
Put both the jdk8 and the jdk7 in your path (put the one you want as "default" first).
Look up java.exe and javac.exe in the jdk8 bin/ directory. Copy the executables under the name java8.exe and javac8.exe.
Do the same in the jdk7 bin/ directory, and copy the binaries to java7.exe and javac7.exe.
Now you can call java/javac, java7/javac7 and java8/javac8.
(I am not sure why anybody would need JAVA_HOME, I never set it.)
The other excutables like jar.exe and so on will be taken from the default jdk (the one first in the path), this is ok, since your JAR files will be the same no matter which jar.exe made them.
Then go on to configure the applications you need, like eclipse.
Hopefully, also your build tool can be told which executables to use. If not, it will use the default.
This way, you can also realize crazy configurations. For example, suppose you want jdk7 as default, but want to always use the java8 javadoc. Then simply rename the javadoc.exe from jdk7, for example to javadoc-dontuse.exe. This way, when you type javadoc.exe or some application calls it, it will not find it in the (default) jdk7 and continue to search in the jdk8 bin.
Related
I see this question has been addressed here Multiple Java versions running concurrently under Windows, I think some things have changed since this question was addressed.
I want to run multiple versions of java on Windows 10. While investigating this I see that Oracle (I think) has modified the PATH env variable on my machine.
There are 2 entries:
C:\Program Files (x86)\Common Files\Oracle\Java\javapath
C:\ProgramData\Oracle\Java\javapath
Both of these entries are symbolic links to my default version of java , 1.10 in my case. I think the easiest way to run multiple versions is to remove both of these entries, add a JAVA_HOME env variable and add %JAVA_HOME%\bin to my PATH env variable. When I want to change java versions I just change my JAVA_HOME variable.
I'm wondering if people think this is the best way to accomplish what I want and also does anyone know why there are 2 different entries pointing to symbolic links for java.
I tend to remove all the java variables from the system and put them in the batch file used to start my java app(s)--if you do this you keep complete control across versions.
Even though java apps tend to work on newer java versions, sometimes a program will install an older java version and modify your path/env, so you should probably have your batch file put your desired java bin path at the head of the path variable and overwrite the java_home variable (I think java_opts is used as well and could be set by your batch file).
You can also have a batch file add to the path and then run "CMD" which launches a new shell. This allows you to develop or run java straight from the command line without permanently modifying your environment.
Java never has a simple command line, so I'd think anyone that had to type java -jar … even once would want to build a batch file so they could just launch it like any .exe anyway, so why not set up your environment in there as well?
On macOS, one can use jENV to manage multiple java versions. There is an alternative of this in Windows - https://github.com/FelixSelter/JEnv-for-Windows/blob/main/jenv.bat
Previously I am using Java 1.8 in my machine. But now i need to use Java 1.6. So I changed the below values in system environment variables.
JAVA_HOME
U:\POC\jdk1.6.0_31
PATH
U:\POC\jdk1.6.0_31\bin\ or %JAVA_HOME%/bin
Also I restarted my system
Even after that it is displaying java version as 1.8 in my command prompt.
Can anyone advice on how to resolve this issue?
when latest version is installed in system it automatically set javapath in environment variable like "C:\ProgramData\Oracle\java\javapath".
Remove this from environment variables.
This suggestion may seem obvious, but I urge you to carefully consider this advice.
I have encountered this issue before, and frequently, it has been due to an overlooked entry within the long list of items making up the Windows Path. It is often an path entry where it is not immediately obvious that any of the java executables (javaw.exe, javaw.exe or javaws.exe) may reside. A common culprit is C:\ProgramData\Oracle\Java\javapath
You will therefore need to push upwards, your desired java/bin path above these. If in doubt, push it right to the top!
In the unlikely event that this does not work, then try making changes from within the java admin console (Control Panel --> Java --> Java tab --> View Button).
I've not used Windows in a long time but I remember that there are 2 sections of environment variables. One system scope, and the other user scope.
Check that nothing in the system scope is defining a JAVA_HOME.
Like #Stephen C said, post the output of echo %PATH% and echo %JAVA_HOME%.
Check that nothing comes before %JAVA_HOME%/bin in the path that may contain the java executable. Things like Oracle client come with Java. You can always put %JAVA_HOME%/bin in front of the path instead of at the end.
#David Santiago's answer is a bad idea. If you let the IDE do your job, you won't be able to troubleshoot when there is a problem.
I recently ran into this as I have added in JAVA 9, 11, and 17 along with my previous JAVA 6, and 8 versions.
I incorrectly assumed that env variables hadn't changed with the newer releases, but I was obviously wrong.
When I ran java -version it returned JAVA 9 and javac -version returned JAVA 17.
So, I incorrectly tried to add a %JAVA_HOME% variable, as I had always done in pre-JAVA 8 versions under the Windows Environment Settings. However, despite moving that addition to the front of the PATH, it didn't change anything!
This article explains the issue: Java SE 8 Update 171 Uses Different Windows Path (Doc ID 2412304.1), however it doesn't give any solutions.
The path to this Windows folder is:
C:\ProgramData\Oracle\Java\javapath
Notice it is under a ProgramData folder, not Program Files. Moreover, it has been prepended to PATH under the Windows env settings. This folder is where java has 3 symbolic links set that will override the PATH changes you make and sure enough it was pointing to the JAVA versions I returned from -version on java and javac. Even if I tried to set a JAVA_HOME as the first entry in path, it still didn't work!
I found two solutions here at: JDK 8 and C:\ProgramData\Oracle\Java\javapath
How to switch JDK version in cmd more flexibly You can either prepend
your own directory to the PATH to overwrite the Oracle one, or follow
the convention to append to the end of PATH variable like always did.
I prefer the second one, here is how to do it.
The second solution uses two batch files with a env variable JAVA_HOME setting similar to what I had always used.
The system displays the latest version installed on the system.
That's informative only, that should not worry you.
If you are going to use version 6.0_31 of the Java JDK you only have to configure that in your IDE (Eclipse, Netbeans, IntelliJ IDEA, whatever) to compile using that version.
Example
On command prompt use these commands to set envirnment variables
JAVA_HOME=C:\Program Files\Java\jdk-11.0.17
set PATH=%JAVA_HOME%\bin;%PATH%
I want to install BlueJ manually for portability reason. I have set Java_Home and add Java bin directory to path environment variable. I'm using a symlink on c:\java which points to d:\java on sd card.
Why BlueJ does not take them into account still pretending it cannot detect jdk.
Update : Eclipse is OK so is there something specific with BlueJ and Jdk 1.8 ?
I've just done a clean install of BlueJ and JDK 1.8 on separate drives to replicate your problem. I made a symlink to the JDK and put that in JAVA_HOME and PATH (from your use of C:\ syntax, I guessed you were on Windows, so I tested on Windows 8.1).
I too found that the setting of environment variables was ignored by BlueJ in selecting a JDK to use when it is running. I could change JDK by using the companion program Select BlueJ VM, but could not enter a symlink there (I believe on earlier versions, changing VM was a setting on the start menu, not a separate program).
In summary:
It is not a problem with BlueJ and Java 8 compatibility
It is not a problem with the symlink
For Windows at least, It is due to the way that BlueJ determines and stores which JDK it uses (both actions via the registry).
You can manually change the registry key to your symlink if you want (see details below), but that's an extra install step.
In detail
I found that BlueJ stores that path to the JDK it uses in the following registry key
HKEY_CURRENT_USER\Software\BlueJ\BlueJ\3.1.5\CurrentVM
Note the root could be HKEY_USERS or HKEY_LOCAL_MACHINE depending on whether you installed for one user or all users of the machine.
The issue is that this key is set automatically if your system has only one VM available at runtime, or on the first run of BlueJ or with the Select BlueJ VM program at any time later. The options offered to you there are the JDK's that the launcher can detect (via the registry) on your system at that moment. Once that value is set, it is not changed dynamically at runtime to reflect JAVA_HOME. Even using the "Browse" option from the options, I could not set the symlink as the JDK location via the GUI.
You can, however, manually change the value of that registry key (e.g. via regedit) to your symlink value (tested and verified OK - might need administrator permissions).
I looked at the source code to determine how CurrentVM is set.
After a fairly short trawl (kudos to BlueJ devs for good naming), I eventually worked out that the actual code used to launch BlueJ is the C++ file in \package\winlaunch\bjlaunch.cc (source file mercurial link here).
That simply checks for the value of the registry key and, if it doesn't exist, if calls findRegistryVMs(), which checks the registry (NOT environment variables) for available VMs and offers those to the user. So, there doesn't appear to be a way to get BlueJ to use the value from JAVA_HOME without a manual registry edit.
N.B. If you do manually change this key value to the Symlink, you can change where the symlink links to and (with a restart) BlueJ will use whichever JDK the symlink linked to. Again, tested and verified on Windows 8.1
N.B. 2 At first, things looked optimistic: in Installer.java there is a method called findJavaPath() that first checks
String javaHome = System.getProperty("java.home");
before having a few guesses if that doesn't work. So it looks like it should respect the value of JAVA_HOME at install time. However, it seems to only use that to check that there is a compatible (1.6+) version of Java available.
Determining the correct path for JAVA_HOME is a bit complex on an Ubuntu system because it uses alternatives. On my machine this is how alternatives creates at least two levels of indirection before it gets to the actual java or javac.
usr/bin/javac -> /etc/alternatives/
/etc/alternatives/java -> /usr/lib/jvm/jdk1.7/bin/javac
If I set JAVA_HOME to /usr/lib/jvm/jdk1.7 , then it is possible that my system java might become inconsistent with the java pointed to by JAVA_HOME, if I update alternatives to use another java.
My question is, what is the correct value for JAVA_HOME on a system that uses alternatives. I am inclined to think that JAVA_HOME should be set to /usr
This way TOMCAT or any other software that uses it, will append 'bin' to JAVA_HOME and find all the executables it needs.
Is this the correct value for JAVA_HOME on systems that use alternatives. Do most software use JAVA_HOME only to locate the executables, or would they use the value to locate other artifacts (such as the security policy fil, etc) that come bundled with the JDK ? If the former is true, then I feel we can use /usr for JAVA_HOME, but if the latter is true, then I think the only way to use JAVA_HOME correctly is by sacrificing the alternatives functionality.
Good question - I use "alternatives" on Linux and everything "just works" - I never really had to think about it.
I believe this is the answer:
JAVA_HOME=/usr/lib/jvm/default-java
What is the correct target for the JAVA_HOME envrionment variable for a Linux OpenJDK Debian-based distribution?
1) "alternatives" sets the symlink to whatever your "real" Java is currently configured to
2) All you need to do is set $JAVA_HOME to the symlink
I didn't find a proper direct solution for the issue, so here is my workaround
add the following to the bachrc
javapath=$( readlink --canonicalize /usr/bin/java)
removebin="/bin/java"
removejre="/jre"
javapath2=${javapath/$removebin/}
export JAVA_HOME=${javapath2/$removejre/}
Then do source to reload the JAVA_HOME whenever you change the java version using alternatives
source ~/.bashrc
Explanation:
What I have done is get the java classpath from the variable set by update-alternatives app and then remove the bin/java part from it and then assign it to the JAVA_HOME. This process happens at login to the system. if you alter the java version in the middle of a session you will have to reload the profile.
I use Eclipse with ant scripts, and Eclipse works well with the default JRE installation on Windows XP.
The annoyance comes when I want to run ant scripts compiling with the javac-tag, where it fails because there is no tools.jar in the classpath.
I've gotten the idea that if I could make the JDK become the default Java on Windows, then I would have what I have today, plus ant working out of the box.
Can this be done? What have I missed in the installation process?
Edit: I know of JAVA_HOME, but that is tedious and error prone (manually updating environment variables when a fresher JDK is available is not always something I remember).
Edit: I ended up figuring out how to make the javac task use the Eclipse compiler (ecj.jar), which works very nicely.
Edit: Maven also supports using the Eclipse compiler, but this appears to be very rarely used and with an old version of ecj.jar. I intend to look in to this at a later time.
Edit: Using ecj with maven-compiler-plugin 3.0 works very well, and allows for building with a JRE.
Edit: I had problems with the javadoc tool crashing when parsing bytecode generated by ecj.
The answer is "no," there is no way to get the JDK to be the default JVM upon install.
As the other answers point out, you can adjust your path and your JAVA_HOME to point to the JDK, or a different JVM entirely. This is in fact what the Java installation does in the first place.
However, your problem is that you want tools.jar to be found. To do this you can copy it to the ext directory under your default JVM. Check the JDK file structure here. This will probably work.
On the other hand, if modifying the JAVA_HOME and PATH variables for Java seems annoying, remember that it's just one of a series of things we do to keep us sharp
Download JDK from the website
Once everything is finished, go to Control Panel
Open JAVA
Click on the Java tab and select View
There will be one item present in the list. Change the Java Path from JRE to the JDK you downloaded, like so:
C:\Program Files\Java\<your_jdk_version>\bin\java.exe.
For example, mine looks like this:
C:\Program Files\Java\jdk1.7.0_07\bin\java.exe
Copying the tools.jar file to a location where Eclipse is looking for it may work, but is messy and fragile since that's a step you may not remember the next time you upgrade your JDK. Better is to convince Eclipse to look for it in the proper location.
Setting JAVA_HOME to the correct location works for some tools, but Eclipse does not honor it.
A couple of things to try:
Make sure your JDK is identified and
selected under
Preferences->Java->Installed JREs.
Make sure Ant is being invoked by the
JDK. One clue is that at the top of
the Console output you should see the
path of the javaw.exe which is being
used. If that path is in the JRE,
more convincing is needed. Check
Run->External Tools->External Tools
Configurations->[your Ant build]->JRE
and make sure the settings there
point to the JDK.
Try changing the JAVA_HOME environment variable to point to the JDK instead of the JRE.
Alternatively or possibly additionally, add a PATH entry to the JDK bin directory before any of the Windows system directories.
I suspect JAVA_HOME is enough to get Ant working, but it's sometimes nice to get the JDK version of java etc on the path too, so that when you just run java from the command line, you'll get exactly the same version as when you run javac.
You could probably write a WSH script to reconfigure your path automatically.
This JScript script just prints some info:
//file: jdk.js usage: cscript /Nologo jdk.js
var objShell = WScript.CreateObject("WScript.Shell");
function setJdk(version) {
try {
var jdk = objShell.RegRead("HKEY_LOCAL_MACHINE\\SOFTWARE\\" +
"JavaSoft\\Java Development Kit\\" + version + "\\JavaHome");
if(jdk != null && jdk != "") {
jdk += "\\bin";
var path = objShell.RegRead("HKEY_CURRENT_USER\\Environment\\Path");
path = jdk + ";" + path;
WScript.Echo("Could set PATH to " + path + "\n");
}
} catch(err) { /*probably key does not exist*/ }
}
setJdk("1.7");
setJdk("1.6");
setJdk("1.5");
There is a RegWrite method that can be used to write to the registry. There is a bit of work involved determining the latest version and rejigging the path, removing obsolete entries and sorting out system versus user paths. No doubt it could be used to set JAVA_HOME too. The JDK entry would need to appear before the system32 directory, as the JRE installer puts a java.exe in there.
(I'm not 100% sure if the shell would pick up on such changes or whether a reboot/env variable reload of some kind would be required.)
This is normally done by setting your JAVA_HOME environment variable to the root JDK directory that you want to use.
For example from a command line or batch file you simply do something like:
set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14
However to set JAVA_HOME permanently add it to the environment variables on the Advanced tab in the property sheet for My Computer.
Apparently Eclipse can compile without the tools.jar. My guess it that they have a specific javac command that can work with a JRE (and not a JDK); this could be the reason why they can list their warnings.
Anyway, I would go the standard way (as suggested above) and install a JDK on your system. You can even start Eclipse with that specific JDK (without any JAVA_HOME change) by tweaking the eclipse.ini file (see these instructions).
Of cause this is doable. Not understand why people said No to this question.
Copy over the tools.jar is not a wise way, I had the issue when using eclipese,
Just add the jdk instead of jre to my build path and it works.
Here is the details:
http://www.gamefromscratch.com/post/2011/11/15/Telling-Eclipse-to-use-the-JDK-instead-of-JRE.aspx