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
Related
I want to install Oracle JRE 1.8.202 x64 without making any changes to the current default java on target machines.
Detail on what I mean by 'Default Java'. I mean I don't want the installer to change of any of the settings that any current or old Java installer may have made to make itself the default (e.g. path changes, java executables dumped in windows or system32 directories, java.exe added or updated to C:\ProgramData\Oracle\Java\javapath\java.exe, environment variables like JAVA.HOME, Java executables added to registry apppaths).
The target machines are a mix of Windows machines that will have a huge variety of current Java installations. Some apps in the target environment rely on using the default java to run - I'd rather they didn't, but that's out of my control.
I can't see any options to stop the installer (jre-8u202-windows-x64.exe) setting it's JRE to the default. See the installer switches at Oracle JavaSE 8 Docs.
Anyone know of any methods other then just copying the files into a target directory?
Snapshotting the current default then restoring it is not an option - Oracle have changed 'setting the default' technique over time, so restoring cleanly would be a fragile rabbit hole.
For both JDK and JRE installations, Oracle differentiates between "patch in place" and "static" installations, where the former refers to updating an existing JRE with newer components in an existing directory, and the latter refers to performing a standalone install.
You want to run the install via command line:
jre-8u251-windows-i586.exe f:\jre_config_file
where jre-8u251-windows-i586.exe is the latest version of JRE 8 (of course you can specify whatever flavor of JRE 8 you're actually after), f:\jre_config_file is a file containing the line STATIC=1 and any other config options you're after.
You could also just feed the installer STATIC=1 as a command line arg.
The STATIC option is actually listed in the page you linked, so I'll spare you additional blather about config.
I'm not sure if it's the best method but you could try using SDKMan to manage your Java versions on your target machine.
I did not find a managed way to use the installer without changing target system default java.
Instead, a custom installation process copies the installation tree into the target directory. Works fine.
I have created an executable JAR file developed on Java version 8. The JAR file was opening on double click. But as the Oracle applications support only Java 6, I had to install JRE 6, but then after the JRE 6 installation, my executable JAR file is not opening.
I have set the JDK 8 bin path in Path environment variables. Is there a solution for this problem? Why is the JAR file not opening after two Java versions in the system?
JAR should open even if two versions 6 and 8 of Java are installed in the system.
You are facing a backward compatibility problem. Backwards compatibility means that you can run a Java 6 program on a Java 8 runtime, but not the other way around.
You can run a lower configuration on a higher configuration, not vice-versa
There are several reasons for that:
Bytecode is versioned and the JVM checks if it supports the version it finds in .class files.
Some language constructs cannot be expressed in previous versions of bytecode.
There are new classes and methods in newer JREs which won't work with older ones.
If you really, really want (tip: you don't), you can force the compiler to treat the source as one version of Java and emit bytecode for another, using something like this:
javac -source 1.8 -target 1.6 MyClass.java
You can compile your code to Java 1.6 bytecode using JDK 1.8. Just take care of the following:
-source=1.8 and -target=1.6 compiler options
If you use Maven, consider having two pom.xml files, with an optional parent file.
Source: Can program developed with Java 8 be run on Java 7?
I am not sure if this solution going to work or not.
Try to run command java -version and look if it returns java 6 or 8 path. Also try to give path of JDK 8 as JAVA_HOME variable and add that into path like this path=%JAVA_HOME%/bin and see if it works. If you get the java 6 as java version try to use above method and then install JRE 6
Hi All Thank you for your response. I kept java6 and reinstalled java8 and now forms and jar both are working!.
In the short term,
the answer is yes. Since both JDK files are downloaded as jar fils it will ok to download both jar files. The reason to not opening after two java versions is as #Elliott said: "in the system is Java 6 can't run Java 8 compiled code, you should be getting an error." That's exactly true but the problem is how to use multiple versions of JDK in a single machine.
Then we have to move on to long term,
The tricky thing is to manage these multiple JDKs and IDEs. It’s a piece of cake if I just use Eclipse for compiling my code because the IDE allows me to configure multiple versions of Java runtime. Unfortunately (or fortunately), I have to use the command line/shell to build my code. So, it is important that I have the right version of JDK present in the PATH and other related environment variables (such as JAVA_HOME).
Manually modifying the environment variables every time I want to switch between JDKs, isn’t a happy task. But, thanks to Windows Powershell, I’m able to write a script that can do the heavy lifting for me.
Basically, what you want to achieve is to set the PATH variable to add the Java bin folder and set the JAVA_HOME environment variable and then launch the correct Eclipse IDE. And, I want to do this with a single command. Let’s do it.
Open a Windows Powershell.
I prefer writing custom Windows scripts in my profile file so that it is available to run whenever I open the shell. To edit the profile, run this command: notepad.exe $profile - the $profile is a special variable that points to your profile file.
Write the below script in the profile file and save it.
function myIDE{ $env:Path = “C:vraajavajdk7bin;” $env:JAVA_HOME = “C:vraajavajdk7” C:vraaideeclipseeclipse set-location C:vraaworkspacemyproject play }
function officeIDE{
$env:Path = "C:vraajavajdk6bin;"
$env:JAVA_HOME = "C:vraajavajdk6"
C:officeeclipseeclipse
}
Close and restart the Powershell.
Now you can issue the command myIDE which will set the proper PATH and environment variables and then launch the Eclipse IDE.
As you can see, there are two functions with different configurations. Just call the function name that you want to launch from the Powershell command line (myIDE).
If any issue please put a comment below!
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 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.
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.