My Java version is :
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
I don't set JAVA_HOME in my ~/.bash_profile, but I can use both javac and java!
My .bash_profile looks like this:
export EDITOR="vim"
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
export MAVEN_HOME="$HOME/opt/maven"
export PATH="$PATH:$MAVEN_HOME/bin"
If I want to install other version of the JDK like 11,14,15...., how can I use that? Do I need to setJAVA_HOME?
And if I have multiple versions of JDK installed at the same time, how can I use them at different times as needed? What I see on the Internet is to configure Java_ Home, I don't know what to do at all, because I'm worried that after I install several other versions of JDK, they won't work.
I use MacOS Big Sur.
JAVA_HOME is widely misunderstood.
Java itself (i.e. the java, javac and related executables) doesn't actually care about JAVA_HOME.
When they are executed they know which JDK to use (the one they are associated with). The only relevant thing is that your shell (or other tool) finds the executables in the first place and for this PATH is used. Note that PATH is a general-purpose variable used by basically all widely used general purpose OS today to find executables. It's not a Java-specific thing.
In other words: when launching java directly from the shell, only PATH is relevant.
So why does JAVA_HOME come up so frequently?
Some third-party tools (such as Gradle, Maven, Tomcat and various others) will use JAVA_HOME to find the appropriate JDK/JRE to execute. Most of the ones that do will fall back to whatever is on the PATH if no JAVA_HOME is set.
So if you use such a tool and you want to specify a specific Java version then you can set JAVA_HOME as an additional hint.
It might be a good idea to set JAVA_HOME to point to your preferred Java runtime, but it's not necessary for many things.
One commonly used pattern is to define a JAVA_HOME to point to your preferred JDK and then use that to set up your PATH. This way the two will be aligned and if the preferred JDK changes, you only need to change it in one point:
export JAVA_HOME="/some/path/pointing/to/a/jdk"
export PATH="$JAVA_HOME/bin:$PATH"
I have had good experiences with sdkman. You can easily install different JDKs and switch between them. All required environment variables will be set by sdkman!
You can use Jenv which let you maintain different version of JDK and set JAVA_HOME dynamically.
You can also set specific Java version for different folder by having a file named .java-version and mention the java version.
Related
I am working on a legacy project with Glassfish 3 and Java 7. The problem is in order to run Eclipse, I need Java 8. When I install Java 8, I can no longer run Glassfish under Java 7 for some reason.
I do see the two JDKs in control panel for User tab in Java Runtime Environment Settings, but under System once I install Java 8, I only see Java 8 there. So it just runs under Java 8 from what I can tell.
This is my first week of Java.
Simply specify the needed JDK for your Glassfish domain:
Find this configuration file: C:\servers\glassfish\config\asenv.bat (this path is an example)
Edit the file, comment the previous JDK and add the wanted one:
REM set AS_JAVA=C:\Program Files\Java\jdk1.8\..
set AS_JAVA=C:\Program Files\Java\jdk1.7\..
When you install a new JVM, usually it sets itself as the default version on that platform which is the first one found on the Path environment variable. In order to find what version is the default one, run this command: java -version and the output will be something like:
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2ubuntu0.16.10.2-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)
As you see in this case the default one is OpenJDK-8.
If you want to change that, you have to do some changes which depend on the platform can vary but usually you should:
Change JAVA_HOME environment variable to point to desired JVM
installation path
Add desired JVM <installation-path>/bin to Path environment variable and remove other JVM paths.
(Detailed example for Windows, Example for Ubuntu)
Notice that, this potentially could affect every program that uses Java and does not explicitly reference a specific version of Java in its config.
But If you want the default version to remain intact and only make an exception for some programs you have to do it in their config/settings.
For Example for Eclipse you can modify eclipse.ini file and specify the JVM it uses by adding this line (more info):
-vm
/opt/oracle-jdk-1.8.0/bin/java
or for Windows:
-vm
C:\Java\JDK\1.8\bin\javaw.exe
there is a similar config for glassfish too. You can choose which JVM should be the default version and which the one exceptional programs gonna use, In your case I recommend that keep version 7 as default and change eclipse config to use version 8.
I got the following warnings, but don't understand why. It appears I have Java 7U71.
LNGRDUM-4157808:bin xyx$ ./cassandra -f
Cassandra 2.0 and later require Java 7u25 or later.
LNGRDUM-4157808:bin xyz$ java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
What I don't know is why it says you need to upgrade, even though it appears that your Java version is up to date. What I do know is that I had a similar issue recently, and I resolved it this way:
Install the latest JRE from https://www.java.com/en/download. This will install the latest version of Java, but it will NOT update the default "java" used by Terminal/bash, and so Cassandra won't pick it up.
To make Cassandra and Terminal use the newest version, add the latest install to your $PATH. This is complicated for a few reasons. First, it's not obvious where Java installs itself, and it ISN'T to the default /user/bin/java location. It turns out that it's in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin. Second, there's a space in the directory, so you have to be careful about that.
Theoretically, it should be possible to edit your $PATH by editing /etc/paths. However, I was not able to get this to work (maybe something to do with the space in the directory?). Instead, I ended up editing my $PATH a different way, as shown here. The line in my .bash_profile looks like this:
export PATH="/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin":$PATH
If you have any trouble doing this, just let me know.
Test that you've done this properly by opening a new Terminal (this is important as it will reload your .bash_profile), then typing java -version. Hopefully this now displays an even newer version than before. You can double-check that java is being sourced from the right place, and you've successfully modified your $PATH, by typing which java.
Doing that fixed my Cassandra. Hopefully it will fix yours, too.
You must have multiple Java versions installed. Check your PATH setting and change it to point to the correct version:
LNGRDUM-4157808:bin xyx$ SET
. . .
PATH=<bunch of stuff>:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/bin
If JAVA_HOME is set (doesn't need to be for running Cassandra), make sure it isn't pointing to a different Java installation.
I am trying to uninstall java through control panel-->uninstall, however when I run cmd and type java -version, I still obtain:
java -version
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java Hotspot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Thanks.
You should check your path from the command line.
I have multiple JDKs and JREs installed and if needed (for an old application), I change my path.
Go to your command like, type path and hit enter.
Also, in order to see the JAVA_HOME, type echo %JAVA_HOME% in your command line.
Check exactly which version of java is still installed on your system.
Then find it in the control panel and remove it.
Please provide feedback. The more extreme solutions would be:
Try another uninstaller such as revo uninstaller (I am not affiliated with them).
Remove the directory, also the entries in your environmental variables (path, etc).
Option 2 is the last solution and not the best.
Open cmd
C:> for %i in (javac.exe) do #echo. %~$PATH:i
If you have a JDK installed, the Path is displayed,
for example: C:\Program Files\Java\jdk1.7.0_07\bin\javac.exe
You can remove them.
And you have to remove JAVA related system variables by going here
Start -> Computer -> System Properties -> Advanced system settings -> Environment Variables -> System variables -> PATH.
It seems you are having another java installed in your machine. Go to environment variable as said here then find out where your JAVA_HOME has been set and remove that installed java from your system.
Restart the windows system and check again.
prior to restart remove JAVA_HOME and PATH variable from system environment variables.
if still the problem persists that mean you have jre left with uninstalled. so,check properly and try to find it and uninstall it.
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'm using a Windows .bat script and I set JAVA_HOME as C:/Program Files/Java/jdk1.6.0_32
when I do a java -version, it still shows the 1.3
How can I fix this? What am I doing wrong?
For me the issue was in my PATH variable, C:\ProgramData\Oracle\Java\javapath; was added by java windows install before my %JAVA_HOME%\bin;.
So I'd echo %JAVA_HOME% pointing to a JDK7 and java -version showing jdk8.
I'd to put %JAVA_HOME%\bin; before C:\ProgramData\Oracle\Java\javapath; so that java -version displays jdk7.
Try %JAVA_HOME%\bin\java -version
If you modify JAVA_HOME, it's usually better to invoke java with an absolute path (using JAVA_HOME) because the new binary is probably not in the path (and then Windows will load the wrong binary).
Make sure that the PATH environment variable is pointing to %JAVA_HOME%\bin.
Be sure not to mix the system variable path and the user variable system path. I feel OK in calling java without the absolute path (when I know how JAVA_HOME and PATH are configured).
Calling java -version from command line, causes cmd.exe to do the lookup on the "known" directories. "Known" means PATH environment variable. It seems that your PATH contains a java 1.3 bin folder, and not 1.6.
JAVA_HOME is another variable, that is used (for example, and not only) by java wrappers, or by scripts executing some java stuff.
Try doing this:
SET JAVA_HOME=C:/Program Files/Java/jdk1.6.0_32
%JAVA_HOME%/bin/java -version
Add quotes where needed.
I had similar issue,in my case , I had two versions java installed. it can be fixed by uninstalling one version of java completely from system.
Had a similar scenario today - two Windows 10 devices - both have JRE 1.6 & 1.7.
When typing
Java -version
One device shows 1.6 the other 1.7.
This was preventing me running a third party JAR to install some software on the device showing 1.6 (which worked fine on the device showing 1.7 when running java -version), using:
java -jar ThirdParty.jar
As the JAR needed to be run by 1.7.
Cause of this was in the PATH environment variable - one device had the location of 1.6 first in the PATH list, moving the 1.7 location above the 1.6 location resulted in consistency using Java -version and allowed me to install the software.
java -version will consult the paths in the special environment variable Path. You need to select the java version you want and move it upwards the latter (click "Move Up"). You probably have that reference to JDK 1.3 in Path above your addition of JDK 1.6. Since that's the first thing the OS finds, that's what it chooses to run.
Executing the command again with the same window opened after changing the environment variables will not work. Re-open it
I know this question is old but this was my case and I wanted to re-explain further, similar to #DanBot 's case