Develop Reference

Upgrading Jenkins Java version from 8 to 11

I'd like to upgrade java from 8 to 11 as recommended for Jenkins 2.303.1, I'm reading the guide in https://www.jenkins.io/doc/administration/requirements/upgrade-java-guidelines/, but I don't know what to do in step:
Use a package manager to install the new JVM. Make sure the default
JVM is the newly installed version. If it is not, use the correct java
command in the Jenkins startup scripts (/etc/default/jenkins or
/etc/init.d/jenkins).
does it mean install Java 11 and set java 11 is default one?

Note: since June 2022, you do not have a choice anymore.
JDK 11 will need to be the one running Jenkins.
It does not have to be the "default" on your system. Only the one selected in the command use to run Jenkins.
Jenkins requires Java 11 (Basil Crow)
Beginning with Jenkins 2.357 (released on June 28, 2022) and the forthcoming September LTS release, Jenkins requires Java 11.
Additionally, beginning with Jenkins 2.355 (released on June 14, 2022) and Jenkins 2.346.1 LTS (released on June 22, 2022), Jenkins supports Java 17.
Plugins have already been prepared in JENKINS-68446.
Use the Plugin Manager to upgrade all plugins before and after upgrading to Jenkins 2.357.
Warning regarding JAXB
Prior to Java 11, Java Architecture for XML Binding (JAXB) was part of the Java Platform, and one could use it without adding a third-party dependency.
Beginning with Java 11, JAXB is no longer a part of the Java Platform and requires adding a third-party dependency.
Thanks to work done several years ago by Baptiste Mathus and others, a JAXB Jenkins plugin is available, which provides the JAXB library to Jenkins plugins in the form of a plugin-to-plugin dependency.
The vast majority of plugins have already been prepared to support Java 11 via the JAXB plugin in JENKINS-68446.
Jenkins users need only upgrade plugins to compatible versions as documented in the Released As field in Jira.
It is critical to use the Plugin Manager to upgrade all plugins before and after upgrading to Jenkins 2.357.
Failure to upgrade plugins to compatible versions may result in ClassNotFoundException, NoClassDefFoundError, or other low-level Java errors.
Upgrade
Docker
The official Jenkins Docker images have been based on Java 11 for many months, with Java 8 available as a fallback and Java 17 available in preview mode.
Beginning with Jenkins 2.357, the Java 8 images will be retired and the Java 17 images will transition from preview to general availability (GA). Users of the official Jenkins Docker images need not install or configure Java on their own, as it comes preinstalled in the image.
OS packages
Users of the official Jenkins OS packages for Debian, Red Hat, and SUSE Linux distributions should note that these packages are agnostic to the Java vendor. >
In other words, you must bring your own Java package. One straightforward way to do this is to install Java 11 from your Linux distribution, as described on the package download site
Recommenced Garbage collection options
-XX:+AlwaysPreTouch
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=${PATH}
-XX:+UseG1GC
-XX:+UseStringDeduplication
-XX:+ParallelRefProcEnabled
-XX:+DisableExplicitGC
-XX:+UnlockDiagnosticVMOptions
-XX:+UnlockExperimentalVMOptions
-Xlog:gc*=info,gc+heap=debug,gc+ref*=debug,gc+ergo*=trace,gc+age*=trace:file=${PATH}/gc.log:utctime,pid,level,tags:filecount=2,filesize=100M
-XX:ErrorFile=${PATH}/hs_err_%p.log
-XX:+LogVMOutput
-XX:LogFile=${PATH}/jvm.log
Agents
For best results, it is recommended to run agents with the same version of Java as the version used on the controller.
Use the Versions Node Monitors plugin to verify that agents are running a compatible version of Java.
Running the Jenkins remoting process on an agent with Java 11 or 17 does not imply that you need to run your builds with the same version of Java.
You can continue to use any desired version of Java for individual builds.

I opted to not install Java on the system, and followed the below approach:
Go to Java 11 Downloads (registration on oracle.com required)
Download the latest Java 11 Compressed Archive (zip) file. At the time of writing: jdk-11.0.15_windows-x64_bin.zip
Unzip this on your build server, keep the path where you extracted to for step 5
Backup Jenkins Home, especially your jenkins.xml file (same folder as jenkins.war).
In Jenkins.xml, update Executable to extracted path, e.g. C:\Java\jdk-11.0.11\bin\java.exe
Restart Jenkins Service

However you have (OpenJDK) 11 installed, as long as you have either JAVA_HOME=/path/to/jdk11 and PATH=$JAVA_HOME/bin:$PATH or explicitly run /path/to/jdk11/bin/java -jar jenkins.war or if you type java -version and it returns "11", you are fine.
Note: that is to launch jenkins. You can set the JDK available to your jenkins jobs from within Manage | Global Tools Configurationtion.
2nd Note (updated): the documentation has been updated (2021-09-16) ... The default Docker image jdk as of 2.303.1 is now 11, so you don't need to append ”-jdk11", rather users must append "-jdk8" if users want to stick to 8.

if you have Centos you can do the following(i have done this for Centos7 and Jenkins 2.367)
sudo yum install java-11-openjdk
yum install output
if have issues with repos and you want do this manually
you get the rpm's that you want and then :
first update the dependency .
sudo rpm -Uvh tzdata-java-2020a-1.el7.noarch.rpm
and then
sudo rpm -Uvh java-11-openjdk-headless-11.0.8.10-1.el7.x86_64.rpm
sudo rpm -Uvh java-11-openjdk-11.0.8.10-1.el7.x86_64.rpm
then you can give
sudo update-alternatives --config java
to find the java path of java 11 --> /usr/lib/jvm/java-11-openjdk-11.0.8.10-1.el7.x86_64/bin/java
it should not be the default, if you don't want to ,you can just copy it
and use it to jenkins nodes Java path at configure nodes
jenkins JavaPath

You have two options: You can globally install Java 11 on your system, for example using a package manager like apt. You would then make Java 11 your default Java.
The other option is to manually install Java, for example OpenJDK, and extract it to, for example, /opt/java and adjust the Jenkins startup script to use that specific Java installation.

I just upgraded a Jenkins installed from apt packages (from: http://pkg.jenkins-ci.org/debian/) with the following steps (inspired by: https://www.jenkins.io/doc/book/installing/linux/)
First, install java 11:
sudo apt install openjdk-11-jre
Then check java -version
which may still show openjdk version "1.8.[x]"
If so, do choose a java-11 alternative with:
update-alternatives --config java
Then java -version should show openjdk version "11.0.[x]"
Then you can do:
systemctl restart jenkins

docker exec -it <container_id> /bin/bash
If permission denied error, then,
docker exec -u 0 -it <container_id> /bin/bash
sudo apt-get update
sudo apt-get install openjdk-11-jdk
export PATH=$JAVA_HOME/bin:$PATH
java -version

Switching Java 11 for Java 8 on the server

So I've seen a bunch of tutorials on switching from Java 8 to Java 11, but I actually need to do the opposite. And I am doing it on a server, so I can use only bash.
I am pretty clueless of how to do it. Any help?

You can run this command and chose version java:
sudo update-alternatives --config java

This is what I do on my Debian system:
alias j8='export JAVA_HOME=/usr/lib/jvm/bellsoft-java8-full-amd64;export PATH=$JAVA_HOME/bin:$PATH'
This will ensure all executables are of the same version, and is a lot easier than update-alternatives, even if it did work (see my comments below another answer) or update-java-alternatives and is less error-prone

I use this tool SdkMan Install, SkMan manual
skd list java
print the versions of java available, and you can install it with comands like
sdk install java 8.0.292.hs-adpt
After you install a java version with sdkman set the java Home with
export JAVA_HOME=~/.sdkman/candidates/java/current
export PATH=$JAVA_HOME/bin:$PATH
you can install many java versions as you want and set your default version with
sdk default java 8.0.292.hs-adpt
If you use maven or gradle install them from sdkman, because in this way autodetects the version switching.
If you want to switch java versions only for specific projects check the env and .sdkmanrc part in the manual. It switches versions when you cd into a directory and go back to default when you cd out.

Oracle JDK 8 on Heroku with a Gradle Build

Does anyone know where I can find a gradle-compatible buildback for Heroku that includes the Oracle Java JDK 1.8?
I'm deploying a reasonably complex spring application and I have a feeling the strange errors are caused by differences between OpenJDK and OracleJDK.
Alternatively, perhaps someone can guide me to forking an existing buildpack and creating my own.
EDIT: It wasn't a JDK issue after all

First of all, this is unlikely to solve your problem. That said...
You can customize the JDK by setting the JDK_URL_1_8 config var like so:
$ heroku config:set JDK_URL_1_8=http://...tar.gz
For Oracle JDK: you must strip the jdk1.8.0_51 dir from the tarball. You can do this by running:
$ tar -xvf jdk-8u51-linux-x64.gz
$ cd jdk1.8.0_51
$ tar -cv -f jdk-8u51-linux-x64.gz .
You should manually download the OracleJDK, edit as per above, and put it in a personal S3 bucket (or some other storage). Then use that URL for your config var.
Be aware that the Oracle JDK is much larger than the OpenJDK (by about 100mb). This will affect your slug size. (The size is mainly due to junk you don't need like GUI stuff and docs).

running neo4j in a machine with java 1.6

I am trying to run neo4j for the first time.
In my RHEL 6 machine, I have Java 1.6 installed. I do not want to change that because other programs are using that. When I tried to run neo4j, downloaded from here, I got the error: ERROR! Neo4j cannot be started using java version 1.6.0_24. Please use Oracle(R) Java(TM) 7. Clearly, I need to install JAVA 7. I was wondering if I can just download Java 7 and let neo4j know the path to java executables.

Set the JAVA_HOME and PATH before starting the neo4j server.
set the path on the terminal.
export JAVA_HOME=/home/jdk/jdk1.7.0_45
export PATH=$JAVA_HOME/bin:$PATH
then start the neo4j or you can create a bash script to do this automatically.

The different major versions are normally different packages (e.g., java-1.7.0-openjdk-devel) that go in different directories (usually in /opt), and you can set the JAVA_HOME and/or JDK_HOME environment variables in your startup script. That said, there's rarely any harm in running your programs on the version 7 JVM (just like you can upgrade the kernel without touching your installed programs), and Java 6 is EOL and won't get new security updates.

neo4j 2.0.2 uses java7 it seems and hence requires jdk7.
Go to neo4j website and download 1.8.3 version
http://dist.neo4j.org/neo4j-community-1.8.3-unix.tar.gz
and if you have java 1.6.45 in ubuntu, you are done
untar and copy to /opt and issue the below command from neo4j root directory
sudo ./bin/neo4j start

Multiple Java versions running concurrently under Windows

We have a couple of applications running on Java 5 and would like now to bring in an application based on Java 6. Can both java versions live together under Windows?
Is there any control panel to set the appropriate Java version for different applications, or any other way to set up, what version of Java will be used to run that particular application?

Of course you can use multiple versions of Java under Windows. And different applications can use different Java versions. How is your application started? Usually you will have a batch file where there is something like
java ...
This will search the Java executable using the PATH variable. So if Java 5 is first on the PATH, you will have problems running a Java 6 application. You should then modify the batch file to use a certain Java version e.g. by defining a environment variable JAVA6HOME with the value C:\java\java6 (if Java 6 is installed in this directory) and change the batch file calling
%JAVA6HOME%\bin\java ...

I was appalled at the clumsiness of the CLASSPATH, JAVA_HOME, and PATH ideas, in Windows, to keep track of Java files. I got here, because of multiple JREs, and how to content with it. Without regurgitating information, from a guy much more clever than me, I would rather point to to his article on this issue, which for me, resolves it perfectly.
Article by: Ted Neward: Multiple Java Homes: Giving Java Apps Their Own JRE
With the exponential growth of Java as a server-side development language has come an equivablent
exponential growth in Java development tools, environments, frameworks, and extensions.
Unfortunately, not all of these tools play nicely together under the same Java VM installation. Some
require a Servlet 2.1-compliant environment, some require 2.2. Some only run under JDK 1.2 or above,
some under JDK 1.1 (and no higher). Some require the "com.sun.swing" packages from pre-Swing 1.0
days, others require the "javax.swing" package names.
Worse yet, this problem can be found even within the corporate enterprise, as systems developed using
Java from just six months ago may suddenly "not work" due to the installation of some Java Extension
required by a new (seemingly unrelated) application release. This can complicate deployment of Java
applications across the corporation, and lead customers to wonder precisely why, five years after the
start of the infamous "Installing-this-app-breaks-my-system" woes began with Microsoft's DLL schemes,
we still haven't progressed much beyond that. (In fact, the new .NET initiative actually seeks to solve the
infamous "DLL-Hell" problem just described.)
This paper describes how to configure a Java installation such that a given application receives its own,
private, JRE, allowing multiple Java environments to coexist without driving customers (or system
administrators) insane...

It is absolutely possible to install side-by-side several JRE/JDK versions. Moreover, you don't have to do anything special for that to happen, as Sun is creating a different folder for each (under Program Files).
There is no control panel to check which JRE works for each application. Basically, the JRE that will work would be the first in your PATH environment variable. You can change that, or the JAVA_HOME variable, or create specific cmd/bat files to launch the applications you desire, each with a different JRE in path.

We can install multiple versions of Java Development kits on the same machine using SDKMan.
Some points about SDKMan are as following:
SDKMan is free to use and it is developed by the open source community.
SDKMan is written in bash and it only requires curl and zip/unzip programs to be present on your system.
SDKMan can install around 29 Software Development Kits for the JVM such as Java, Groovy, Scala, Kotlin and Ceylon. Ant, Gradle, Grails, Maven, SBT, Spark, Spring Boot, Vert.x.
We do not need to worry about setting the _HOME and PATH environment variables because SDKMan handles it automatically.
SDKMan can run on any UNIX based platforms such as Mac OSX, Linux, Cygwin, Solaris and FreeBSD and we can install it using following commands:
$ curl -s "https://get.sdkman.io" | bash
$ source "$HOME/.sdkman/bin/sdkman-init.sh"
Because SDKMan is written in bash and only requires curl and zip/unzip to be present on your system. You can install SDKMan on windows as well either by first installing Cygwin or Git Bash for Windows environment and then running above commands.
Command sdk list java will give us a list of java versions which we can install using SDKMan.
Installing Java 8
$ sdk install java 8.0.201-oracle
Installing Java 9
$ sdk install java 9.0.4-open
Installing Java 11
$ sdk install java 11.0.2-open
Uninstalling a Java version
In case you want to uninstall any JDK version e.g., 11.0.2-open you can do that as follows:
$ sdk uninstall java 11.0.2-open
Switching current Java version
If you want to activate one version of JDK for all terminals and applications, you can use the command
sdk default java <your-java_version>
Above commands will also update the PATH and JAVA_HOME variables automatically. You can read more on my article How to Install Multiple Versions of Java on the Same Machine.

It should be possible changing setting the JAVA_HOME environment variable differently for specific applications.
When starting from the command line or from a batch script you can use set JAVA_HOME=C:\...\j2dskXXX to change the JAVA_HOME environment.
It is possible that you also need to change the PATH environment variable to use the correct java binary. To do this you can use set PATH=%JAVA_HOME%\bin;%PATH%.

I use a simple script when starting JMeter with my own java version
setlocal
set JAVA_HOME="c:\java8"
set PATH=%JAVA_HOME%\bin;%PATH%;
java -version
To have a java "portable"
you can use this method here:
https://www.whitebyte.info/programming/java/how-to-install-a-portable-jdk-in-windows-without-admin-rights

Or use links. While it is rather unpleasant to update the PATH in a running environment, it's easy to recreate a link to a new version of JRE/JDK. So:
install different versions of JDK you want to use
create a link to that folder either by junction or by built-in mklink command
set the PATH to the link
If other version of java is to be used, delete the link, create a new one, PATH/JAVA_HOME/hardcoded scripts remain untouched

Invoking Java with "java -version:1.5", etc. should run with the correct version of Java. (Obviously replace 1.5 with the version you want.)
If Java is properly installed on Windows there are paths to the vm for each version stored in the registry which it uses so you don't need to mess about with environment versions on Windows.

If you use Java Web Start (you can start applications from any URL, even the local file system) it will take care of finding the right version for your application.

Using Java Web Start, you can install multiple JRE, then call what you need.
On win, you can make a .bat file:
1- online version:
<your_JRE_version\bin\javaws.exe> -localfile -J-Djnlp.application.href=<the url of .jnlp file.jnlp> -localfile -J "<path_temp_jnlp_file_.jnlp>"
2- launch from cache:
<your_JRE_version\bin\javaws.exe> -localfile -J "<path_of_your_local_jnlp_file.jnlp>"