Selecting java version windows

Java on Windows: switching to a specific Java version/ runtime

This post show how to have multiple Java runtime environments on your PC and switch between them on Windows so that a particular program uses the version that you want it to.

Background

Due to Java SE Platform licensing changes by Oracle, developers have turned to alternatives such as OpenJDK. The AdoptOpenJDK site provides Prebuilt OpenJDK Binaries for Free (the main line on their landing page) and as you will see, there are numerous versions that you could use:

• JDK 8 Long-term Support ( LTS )
• JDK 11 LTS
• JDK 16 (the latest)
• Each of these could be 32-bit or 64-bit versions and you can choose the JVM that you run (Hotspot vs OpenJ9)

In short, there are options and there are times when you want to run something with a specific version of the JVM or you want to test something with multiple JVMs.

Installing and switching between multiple Java versions

The method that I follow is that I have a folder D:\apps where I put different applications tools that I want to use. Under this, I create a folder called jdk and use that as the main holding folder for all the different JDK / JVM that I want to use. I personally prefer not installin each JVM / JDK into my computer any more but to use them ‘without installation’.

Head on over to the releases page at AdoptOpenJDK to get the package you need. Start by changing the platform to Windows as shown below.

Next, pick the JDK (the full Java Development Kit) or the smaller JRE (Java Runtime Environment) and download the ZIP file version. Remember x86 means it’s the 32-bit version and x64 means that it’s the 64-bit version. If you have a modern (relatively new) Windows 10 PC, it’s almost certainly running the 64-bit version of Windows and will therefore support both the versions. In that case, the x64 is preferable though you may have some programs that don’t work correctly on the 64-bit version and need the 32-bit version.

Once you have downloaded the version (or versions) that you want to get, unzip the package. In my case, I unzip it to d:\apps\jdk so that I have all the JDKs/ JREs in one place. After unzipping, I change the folder names to be something like jdk-11.0.11_x64 and jdk-11.0.11_x86 so that I can easily tell which folder has the 64-bit and which one has the 32-bit.

Running a program with Java basically requires you to do: $ java . and for this to work, it needs two things to be in place:

• The Java version that you want to run must be the first Java installation on the path (so that Windows can find it)
• The environment variable JAVA_HOME must be set to the installation that you want to use

So, for switching Java versions, you need to do this:

set JAVA_HOME=d:\apps\jdk\jdk-11.0.11_x86\ path=d:\apps\jdk\jdk-11.0.11_x86\bin;%PATH% 

The first line sets the JAVA_HOME and the second one moves the x86 version of the JDK / JRE to the path. Note that the JAVA_HOME points to the main directory where the whole installation is, and the path must be to the /bin folder under the JAVA_HOME so that java.exe can be found. After you do this, you should see this:

$ java -version openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK Client VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode) 

To switch to a different version, you just need to set both those items correctly again. For example, in my case, I would do:

$ path=d:\apps\jdk\jdk-11.0.11_x64\bin;%PATH% $ set JAVA_HOME=d:\apps\jdk\jdk-11.0.11_x64\ $ java -version openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode) 

(Notice how the last line shows 64-Bit Server VM since it’s now running the 64-bit VM)

It’s not as convenient as using pik to switch Ruby versions on Windows but I imagine it would be a good idea to write something like pik for this. Also, I did not search if there are tools that let you do this easily but there might well be something.

That’s all there is to it. I noted this down mainly for myself since I need to do this occasionally. If it helps you, that’s great! Please leave a comment if there is something else that you think we should add into the post.

Источник

Beyond Java

Once upon a time, you could use Java without installing it. Nowadays, most operating systems make a developer’s life difficult by trying to help. That’s not a big deal if you need only one version of Java. However, if you need to switch between different versions, it doesn’t suffice to set the environment variables PATH and JAVA_HOME . Here’s what you need to do.

MacOS Big Sur (aka MacOS 11+)

Older versions of OSX were pretty straightforward. Most of the time setting the PATH and JAVA_HOME worked. That’s changed with MacOS Big Sur. In a way, it’s a good idea: just set the version number, and the operation system does the rest for you. The catch is you have to unset (sic!) the JAVA_HOME variable.

So this shell script does the trick:

unset JAVA_HOME /usr/libexec/java_home -v 15.0.1 export JAVA_VERSION=15.0.1

It doesn’t have to be the precise version number. Replacing 15.0.1 with 15 does the trick, too, unless you want to distinguish between, say, 15.0.1 and 15.2.0 .

The bad news is you can’t switch between identical versions provided by different vendors. That’s not as arcane as it sounds: MacOS treats GraalVM as just another Java distribution. You can’t easily switch between GraalVM 11.0.9 and AdoptOpenJDK 11.0.9.

The only solution I found to do so is using brute force. Navigate to the folder /Library/Java/JavaVirtualMachines , cd into the Java version Selecting a Java version. Image published at piqsels.com under a CC0 license by an unknown artist. you’re not interested in, and rename the Contents folder. That’s a fairly reliable way to convince MacOS to ignore that Java installation. When you need it again, you must restore the Contents folder. Chances are you don’t have to destroy the other Java version with the same version number: if MacOS finds a Java version matching the requested version number, it stops looking for other versions.

SDKMAN!

I discovered this option recently, several months after writing the original article. SDKMAN! is a command-line tool for MaxOS, Linux and seral other operating systems based on Unix. It manages Java and a wide range of popular tools in the Java universe. It allows you to choose between Corretto, AdoptOpenJDK, GraalVM Community Edition, Liberica, OpenJDK, SapMachine, and even Zulu. I didn’t test it yet, because after installing it noticed it doesn’t support the Enterprise version of GraalVM, but it looks promising. It looks similar to update-alternatives on Linux systems (see below), only it also covers tools like Gradle, Maven, and sbt, as well as languages like Groovy or Ceylon.

MacOS alternative: jEnv

You can also install a Java version manager. I’ve read about a tool called jEnv. I assume it does the trick, too, but I didn’t test it. As far as I can see, using jEnv isn’t much easier than the manual approach.

Ubuntu (or Linux in general?)

The Unix approach is — well, it’s typical Unix style. Open a terminal window and enter this line:

sudo update-alternatives —config java

After that, things are pretty straight-forward. You can select from a list of Java versions.

Windows

On Windows, the key to success is to never install a JRE or a JDK. You don’t have to. Downloading the zip file and unpackaging is enough. Set the environment variables JAVA_HOME=C:\your\folder\of\choice\graalvm-ce-java11-20.3.0 and PATH=%JAVA_HOME%\bin;%PATH% , and you’re good to go. Just make sure the JAVA_HOME folder contains the folders bin and lib and the PATH contains the file java.exe . Also make sure to add the Java path first in the PATH variable.

If you’ve run a Java installation, this approach may or may not work for you. If it doesn’t, there’s a file called java.exe in the Windows folder. Delete it (but don’t forget to make a backup of the file, just in case!). But if I’m not mistaken, that’s only necessary on older versions of Windows, from the 2010 era. I remember switching to another Java version was a pain in the ass at the time, but the blogosphere doesn’t complain much about the topic, so it seems the problem has been fixed. In any case, Sven Woltmann has collected all the hints you need to install anything between Java 1.2 and Java 15 on your Windows machine.

Источник

Java on Windows: switching to a specific Java version/ runtime

This post show how to have multiple Java runtime environments on your PC and switch between them on Windows so that a particular program uses the version that you want it to.

Background

Due to Java SE Platform licensing changes by Oracle, developers have turned to alternatives such as OpenJDK. The AdoptOpenJDK site provides Prebuilt OpenJDK Binaries for Free (the main line on their landing page) and as you will see, there are numerous versions that you could use:

• JDK 8 Long-term Support ( LTS )
• JDK 11 LTS
• JDK 16 (the latest)
• Each of these could be 32-bit or 64-bit versions and you can choose the JVM that you run (Hotspot vs OpenJ9)

In short, there are options and there are times when you want to run something with a specific version of the JVM or you want to test something with multiple JVMs.

Installing and switching between multiple Java versions

The method that I follow is that I have a folder D:\apps where I put different applications tools that I want to use. Under this, I create a folder called jdk and use that as the main holding folder for all the different JDK / JVM that I want to use. I personally prefer not installin each JVM / JDK into my computer any more but to use them ‘without installation’.

Head on over to the releases page at AdoptOpenJDK to get the package you need. Start by changing the platform to Windows as shown below.

Next, pick the JDK (the full Java Development Kit) or the smaller JRE (Java Runtime Environment) and download the ZIP file version. Remember x86 means it’s the 32-bit version and x64 means that it’s the 64-bit version. If you have a modern (relatively new) Windows 10 PC, it’s almost certainly running the 64-bit version of Windows and will therefore support both the versions. In that case, the x64 is preferable though you may have some programs that don’t work correctly on the 64-bit version and need the 32-bit version.

Once you have downloaded the version (or versions) that you want to get, unzip the package. In my case, I unzip it to d:\apps\jdk so that I have all the JDKs/ JREs in one place. After unzipping, I change the folder names to be something like jdk-11.0.11_x64 and jdk-11.0.11_x86 so that I can easily tell which folder has the 64-bit and which one has the 32-bit.

Running a program with Java basically requires you to do: $ java . and for this to work, it needs two things to be in place:

• The Java version that you want to run must be the first Java installation on the path (so that Windows can find it)
• The environment variable JAVA_HOME must be set to the installation that you want to use

So, for switching Java versions, you need to do this:

set JAVA_HOME=d:\apps\jdk\jdk-11.0.11_x86\ path=d:\apps\jdk\jdk-11.0.11_x86\bin;%PATH% 

The first line sets the JAVA_HOME and the second one moves the x86 version of the JDK / JRE to the path. Note that the JAVA_HOME points to the main directory where the whole installation is, and the path must be to the /bin folder under the JAVA_HOME so that java.exe can be found. After you do this, you should see this:

$ java -version openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK Client VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode) 

To switch to a different version, you just need to set both those items correctly again. For example, in my case, I would do:

$ path=d:\apps\jdk\jdk-11.0.11_x64\bin;%PATH% $ set JAVA_HOME=d:\apps\jdk\jdk-11.0.11_x64\ $ java -version openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode) 

(Notice how the last line shows 64-Bit Server VM since it’s now running the 64-bit VM)

It’s not as convenient as using pik to switch Ruby versions on Windows but I imagine it would be a good idea to write something like pik for this. Also, I did not search if there are tools that let you do this easily but there might well be something.

That’s all there is to it. I noted this down mainly for myself since I need to do this occasionally. If it helps you, that’s great! Please leave a comment if there is something else that you think we should add into the post.

Источник