i want to know if i can run multiple JDK's on my PC and use them all
if i can, what is the value of the PATH on system variable
thanks for help
Yes, you can install as many JDKs as you like. Just put them in different folders.
The one you refer to on the path is your choice - but presumably you'd choose the one that you want to use whenever you type "java ...." commands at the command line. In the absence of any other factors you should probably set this to be your most recent JDK version.
Note that your IDE may support multiple JDKs, for example Eclipse has "Preferences / Java / Installed JREs" where you can set up multiple JDKs/JREs for use with Eclipse.
Related
Imagine, in my Path variable on Windows 7 I have the path to my jdk version 8 already included. Now I start a new project where I am using Java 11 for example and I add the path to java 11 JDK's bin also to the Path variable. I am wondering, if it is required to remove the path to the (old) JDK 8 in this case from the Path variable for a correct working? If I leave it there, will the correct Java version be picked up for the new project? And also: In my IDE, when creating a new project, I also do select a JDK to use. What is this choice used for and what is the specification of the JDK in the path variable used for? I am not very familiar with operating systems, so please explain it :)
1) the system's path variable
The path variable defines where the system will search for executables you are using on the console/shell.
Having multiple JDKs in your operating system's path variable is a bad idea. One will take precedence and you cannot even (or should not) be sure which one it is.
If you need different JDKs for different projects, you may create a script setting the environment. Let's call it configure.bat for Windows. When opening a shell you would first run that script to set all environment variables and probably start needed services.
Use commands like java -version or mvn version to check the JDK you shell is using!
You may alternatively be able to create the environment settings by configuring an instance of your shell in a different way, but I unfortunately can't give you any details about that.
There is an alternative ...
2) the IDE's path variable
In you IDE (Eclipse, IntelliJ) you can also configure the JDK, and more important: you can configure different JDKs for specific code levels and can set the code level (or the JDK directly) on each of your projects individually. While working in the IDE you don't need to run configuration scripts, the IDE will take care of that. Be careful though, when using a system console in the IDE, you might be falling back to 1) then.
3) Maven
In a similar way as in the IDE you can configure:
JDKs (.m2/settings.xml)
code levels (the project's pom.xml or one of the parent POMs)
when using Maven. For more details see:
http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
This should be possible for other build management tools like Gradle. I have to refer you to a web search for those, though.
It is a know problem, when you update Java, JDK or JRE, on Windows Eclipse will likely to fail to start as it points to outdated JDK/JRE folder. Fix is relatively simple, it was discussed and solved on several threads like here or here.
But I found those solutions unsatisfyingly inflexible. This solutions suggest to manually fix path in eclipse.ini to something like:
-vm C:\Program Files\Java\<jdk-version-just-installed>\bin\javaw.exe
This means you have to do it after every update, again and again. If you update JDK frequently, and everyone should to have latest security patches, that makes it very annoying.
I expect that after a smart installation every Java program would just run out of box without any manual step involved; any solution less than that I would not consider satisfactory.
I can think of two ways:
using environmental (system) variable like JAVA_HOME. Can eclipse.ini reference environmental variables?
using symbolic link pointing to the latest JDK. And if you wonder, yes, Windows with NTFS support symlinks.
Both ways however need some cooperation from the installer, both JAVA_HOME or symlink as to be updated to the new value. Automatically of course, otherwise there would be no reason why to have them in the first place.
Please correct me if I am wrong, but JDK/JRE installation on linux does exactly that, provides and updates symlink to latest JDK/JRE. Why not Windows installer?
Is there a hidden parameter, option or a toggle in Java install tool doing that?
If not, is there a better, an alternative installation tool?
Can Eclipse launcher itself find a latest Java?
Is there a better eclipse.ini parameter for that?
The purpose of specifying the VM in either eclipse.ini or on the command line is to isolate it from system updates. For example, in the past it has been a big problem that some programs install their own JVM and include it on the system PATH (Oracle was particularly bad about this). So the entire idea is to isolate Eclipse from those kinds of changes; it should not care what other JVMs you have on your system, it refers to a "known" good one for running Eclipse.
Another alternative is to place a JVM directly under the Eclipse installation directory, in a directory named jre, as documented here. I don't personally ever do that, however; I find it to be unnecessary and cumbersome.
What I do that would probably help you is to not install JVM updates into separate directories with names that reflect the actual update version. Instead, I install JDKs into a consistent place based on the major java version. For example:
/Java/
/JDK/
/1.7/
/bin/
<etc...>
/1.8/
/bin/
<etc...>
That way, in eclipse.ini (or any other place a need to refer to a particular JVM) I just use /Java/JDK/1.8 and that will continue to work no matter how many updates I install into that location.
What we do to avoid this problem: We have custom dedicated JDK's for our development environment (for eclipse and for our products), which are not 'attached' to the system. We're using softlinks e.g. ../app/jdk which links to a specific jdk, for intellij we have a ../app/intellij-jdk softlink.
Not sure who to do it in windows, but in linux you download the gzip and extract it, withing messing up your system, like paths, I think for windows you can only download the installer, but it's possible to only extract the actual software from the executable.
Older Windows JDK installers used to copy java.exe and javaw.exe (and also javavm.dll I think) in c:\windows\system32 to make them available in the default path.
In recent installers, a symbolic link is created for java.exe, javaw.exe and javaws.exe in C:\ProgramData\Oracle\Java\javapath. This means that these executables will point always to the most recent JDK update.
I always wondered why I have to manually set the JAVA_HOME environment variable after installing the Java SDK.
JAVA_HOME=c:\Program Files\Java\jdk1.6.0_12
Visual Studio at least provides a batch file to set these kind of environment variables:
call "c:\Program Files\Microsoft Visual
Studio 9.0\VC\vcvarsall.bat"
Does Java have something similar? I'm trying to make a build script that should simply work after installing the Java SDK. I don't want people to mess with environment variables on their PC.
You can install as many versions of Java as you like.
It would be dangerous for the setup to modify a local environment variable such as JAVA_HOME, since it might reference an existing Java installation.
This has nothing to do with an alleged "platform dependent issue". ;)
Since scripts might depend on JAVA_HOME to launch themselves, again, this would be disasterous for a new Java install to modify JAVA_HOME: all those scripts would suddenly have to be launched with a new potentially incompatible JVM.
Plus, by setting $JAVA_HOME/bin or %JAVA_HOME%/bin in your path, you can dynamically change JAVA_HOME to whatever version of Java you want to use without having to much with your PATH variable.
Michael Borgwardt has made in the comments the interesting followup's question
Still, this does not explain why the installer does not set JAVA_HOME when it is not previously set at all.
The answer is simple:
The setup cannot know if a script already depends on JAVA_HOME or not.
Meaning: some scripts could test for JAVA_HOME value, and if not set, refer to another JVM installed elsewhere (and do not forget that by "install", one can only refer to "copied": a JDK/JRE is not always installed by a setup)
If you set JAVA_HOME, that can disrupt the default behavior of some of your scripts.
Not wanting to disturb hypothetical scripts that depend on a env var not being set sound pointlessly paranoid to me - If a script does that, then it clearly WANTS to use a different JVM when one is installed - no reason to avoid that.
Mmm... Sweet. For dealing with massive deployment issues on a daily-basis (for internal application in my shop), I can assure you: it is very sane "paranoid"
treat to have.
When you deploy to a (very) large set of users, you do not want to make any assumption about their platform and configurations. "clearly WANTS" is an assumption I would not dare to make (or I redirect my phone to yours ;) and you handle the angry calls).
For instance, we have many scripts which launches with a 1.4.2 JVM from sun (JAVA_HOME not set on development platform, default path set directly in the script), or with 1.4.2 from JRockit (JAVA_HOME set, as it is the intended target on integration, pre-production and production platforms).
But we install regularly the new JDK1.6.x since we use it for launching eclipse.
Assume that those scripts want their JAVA_HOME set... and nothing works anymore.
... To which Robert Grant makes this on-the-spot critic:
You're describing scripts that require one specific version, but still look at global JAVA_HOME. That's just badly thought out scripts.
While that may or may not be true, that also illustrates precisely my point:
"you do not want to make any assumption": no assumption on their platform/settings, and no assumption on their "best practices".
The former may sound paranoid, the latter is plain common-sense: thinking that your product (here a JDK setup) will not break anything on the user's environment because the user has "correctly" thought out his scripts... would be insane.
GvS suggests:
Or it could just have option to do it, disabled by default
That would mean another option to include in the setup screens, option which should be carefully reviewed by the user, and which may have unintended consequences, even when the user selects it thinking he knows what he is doing...
It is simply not worth it.
I don't think JAVA_HOME is a convention invented or supported by Sun.
They probably remember the fiasco that was the CLASSPATH environment variable** all too well and prefer to stay the hell away from environment variables.
** This was encouraged as the primary way to set the JVM classpath in earlier Java SDKs and literature, and resulted in the user and various applications messing with the environment variable, overwriting each other's changes and depending on mutually contradictive contents.
The vcvarsall.bat mechanism is a convenient way for Visual C++ to provide a console with the correct variables without messing with the user's/system's environment variables. However, it assumes that Installshield is the only way to get code onto the system. The JDK should tolerate being cut'n'pasted from one location to another.
If you're looking for java.exe, the Installshield installer should put it in %windir%\system32, so it is available on the PATH.
You can gain some hints about the location of installed apps by querying the registry:
C:>REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.6" /v JavaHome
! REG.EXE VERSION 3.0
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.6
JavaHome REG_SZ C:\dev\Java\jdk1.6.0_05
However, you can't rely on this absolutely because this makes some assumptions about vendor, version and installation mechanism.
This may help someone else out who ends up here like me. I just want to use Java as a tool, not adopt it as a way of life, so I only needed to know how JAVA_HOME was getting set and why it was not correct. The answer turned out to be that the WinAnt installation sets JAVA_HOME (along with ANT_HOME), but only based on the currently installed Java. So if you need to change the version of Java, and you are using Ant, the correct way to do it is to uninstall WinAnt, uninstall Java, install the new Java, and then reinstall WinAnt.
I'm not sure why this is, because the installers clearly solve platform dependant issues (which is ofcourse the whole point of a JVM). Are you sure you aren't mixing the JRE with the JSDK?
Maybe there's a way for your program to search where java is installed (that would be a script I guess), and then set JAVA_HOME and possibly add it to the path.
IBM seems to be doing this trick already:
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21199220
Other interesting post hinting at the difference between JRE and JSDK installations:
http://confluence.atlassian.com/display/CONF26/Set+JAVA_HOME+variable+in+Windows
Hope this helps.
I guess java doesn't want to do anything which is platform-dependent. In Windows, classpaths are set differently from LINUX/UNIX.
As I know, there are two ways to use JDK in windows:
Download JDK installation file and install.
Download JDK binary.
What's the difference between them?
Pros: Simple and easy, all of a sudden everything works. Cons: Everything now uses the new version - which may not be the desired effect.
Pros: You can put it anywhere you like and make sure it is only accessible by code you expect. Cons: More work involved - usually requires manual intervention.
You don't need to unpack, set JAVA_HOME and PATH environment variables manually. This all is done for you.
You should set environment variables below manually, but you may have more than one installation of one major build (different build, for example). Also, you may put it in any place you want it to be in.
I always wondered why I have to manually set the JAVA_HOME environment variable after installing the Java SDK.
JAVA_HOME=c:\Program Files\Java\jdk1.6.0_12
Visual Studio at least provides a batch file to set these kind of environment variables:
call "c:\Program Files\Microsoft Visual
Studio 9.0\VC\vcvarsall.bat"
Does Java have something similar? I'm trying to make a build script that should simply work after installing the Java SDK. I don't want people to mess with environment variables on their PC.
You can install as many versions of Java as you like.
It would be dangerous for the setup to modify a local environment variable such as JAVA_HOME, since it might reference an existing Java installation.
This has nothing to do with an alleged "platform dependent issue". ;)
Since scripts might depend on JAVA_HOME to launch themselves, again, this would be disasterous for a new Java install to modify JAVA_HOME: all those scripts would suddenly have to be launched with a new potentially incompatible JVM.
Plus, by setting $JAVA_HOME/bin or %JAVA_HOME%/bin in your path, you can dynamically change JAVA_HOME to whatever version of Java you want to use without having to much with your PATH variable.
Michael Borgwardt has made in the comments the interesting followup's question
Still, this does not explain why the installer does not set JAVA_HOME when it is not previously set at all.
The answer is simple:
The setup cannot know if a script already depends on JAVA_HOME or not.
Meaning: some scripts could test for JAVA_HOME value, and if not set, refer to another JVM installed elsewhere (and do not forget that by "install", one can only refer to "copied": a JDK/JRE is not always installed by a setup)
If you set JAVA_HOME, that can disrupt the default behavior of some of your scripts.
Not wanting to disturb hypothetical scripts that depend on a env var not being set sound pointlessly paranoid to me - If a script does that, then it clearly WANTS to use a different JVM when one is installed - no reason to avoid that.
Mmm... Sweet. For dealing with massive deployment issues on a daily-basis (for internal application in my shop), I can assure you: it is very sane "paranoid"
treat to have.
When you deploy to a (very) large set of users, you do not want to make any assumption about their platform and configurations. "clearly WANTS" is an assumption I would not dare to make (or I redirect my phone to yours ;) and you handle the angry calls).
For instance, we have many scripts which launches with a 1.4.2 JVM from sun (JAVA_HOME not set on development platform, default path set directly in the script), or with 1.4.2 from JRockit (JAVA_HOME set, as it is the intended target on integration, pre-production and production platforms).
But we install regularly the new JDK1.6.x since we use it for launching eclipse.
Assume that those scripts want their JAVA_HOME set... and nothing works anymore.
... To which Robert Grant makes this on-the-spot critic:
You're describing scripts that require one specific version, but still look at global JAVA_HOME. That's just badly thought out scripts.
While that may or may not be true, that also illustrates precisely my point:
"you do not want to make any assumption": no assumption on their platform/settings, and no assumption on their "best practices".
The former may sound paranoid, the latter is plain common-sense: thinking that your product (here a JDK setup) will not break anything on the user's environment because the user has "correctly" thought out his scripts... would be insane.
GvS suggests:
Or it could just have option to do it, disabled by default
That would mean another option to include in the setup screens, option which should be carefully reviewed by the user, and which may have unintended consequences, even when the user selects it thinking he knows what he is doing...
It is simply not worth it.
I don't think JAVA_HOME is a convention invented or supported by Sun.
They probably remember the fiasco that was the CLASSPATH environment variable** all too well and prefer to stay the hell away from environment variables.
** This was encouraged as the primary way to set the JVM classpath in earlier Java SDKs and literature, and resulted in the user and various applications messing with the environment variable, overwriting each other's changes and depending on mutually contradictive contents.
The vcvarsall.bat mechanism is a convenient way for Visual C++ to provide a console with the correct variables without messing with the user's/system's environment variables. However, it assumes that Installshield is the only way to get code onto the system. The JDK should tolerate being cut'n'pasted from one location to another.
If you're looking for java.exe, the Installshield installer should put it in %windir%\system32, so it is available on the PATH.
You can gain some hints about the location of installed apps by querying the registry:
C:>REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.6" /v JavaHome
! REG.EXE VERSION 3.0
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.6
JavaHome REG_SZ C:\dev\Java\jdk1.6.0_05
However, you can't rely on this absolutely because this makes some assumptions about vendor, version and installation mechanism.
This may help someone else out who ends up here like me. I just want to use Java as a tool, not adopt it as a way of life, so I only needed to know how JAVA_HOME was getting set and why it was not correct. The answer turned out to be that the WinAnt installation sets JAVA_HOME (along with ANT_HOME), but only based on the currently installed Java. So if you need to change the version of Java, and you are using Ant, the correct way to do it is to uninstall WinAnt, uninstall Java, install the new Java, and then reinstall WinAnt.
I'm not sure why this is, because the installers clearly solve platform dependant issues (which is ofcourse the whole point of a JVM). Are you sure you aren't mixing the JRE with the JSDK?
Maybe there's a way for your program to search where java is installed (that would be a script I guess), and then set JAVA_HOME and possibly add it to the path.
IBM seems to be doing this trick already:
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21199220
Other interesting post hinting at the difference between JRE and JSDK installations:
http://confluence.atlassian.com/display/CONF26/Set+JAVA_HOME+variable+in+Windows
Hope this helps.
I guess java doesn't want to do anything which is platform-dependent. In Windows, classpaths are set differently from LINUX/UNIX.