By default, Jenkins will build Java applications using whatever version of Java it finds on the system path, which is usually the version that Jenkins itself is running under. However, for a production build server, you will probably want more control than this. For example, you may be running your Jenkins server under Java 6, for performance reasons. However, your production server might be running under Java 5 or even Java 1.4. Large organizations are often cautious when it comes to upgrading Java versions in their production environments, and some of the more heavyweight application servers on the market are notoriously slow to be certified with the latest JDKs.
In any case, it is always a wise practice to build your application using a version of Java that is close to the one running on your production server. While an application compiled with Java 1.4 will usually run fine under Java 6, the inverse is not always true. Or you may have different applications that need to be built using different versions of Java.
Jenkins provides good support for working with multiple JVMs. Indeed, Jenkins makes it very easy to configure and use as many versions of Java as you want. Like most system-level configuration, we do this in the Configure System screen (see Figure 4-2). Here, you will find a section called JDK which allows you to manage the JDK installations you need Jenkins to work with.
The simplest way to declare a JDK installation is simply to supply
an appropriate name (which will be used to identify this Java installation
later on when you configure your builds), along with the path to the Java
installation directory (the same path you would use for the
JAVA_HOME variable), as shown in Figure 4-5. Although you need to type the path
manually, Jenkins will check in real time both that the directory exists
and that it looks like a valid JDK directory.
You can also ask Jenkins to install Java for you. In this case, Jenkins will download the JDK installation and install a copy on your machine (see Figure 4-6). The first time a build needs to use this JDK, Jenkins will download and install the specified version of Java into the tools directory in the Jenkins home directory. If the build is running on a new build agent that doesn’t have this JDK installed, it will download and install it onto the build agent machine as well.
This is also a great way to configure build agents. As we’ll see later on in the book, Jenkins can delegate build jobs to other machines, or build agents. A build agent (or “slave”) is simply another computer that Jenkins can use to run some of its builds. If you use Jenkins’s Install automatically option, you don’t need to manually install all the JDK versions you need on the build agent machines—Jenkins will do it for you the first time it needs to.
By default, Jenkins proposes to download the JDK from the Oracle website. If your Jenkins installation is behind a proxy server, you may need to configure your proxy settings to ensure that Jenkins can access the external download sites (see Configuring a Proxy). Another option is to provide a URL pointing to your own internal copy of the JDK binaries (either in the form of a ZIP or a GZip-compressed TAR file), stored on a local server within your organization. This lets you provide standard installations on a local server and makes for faster automatic installations. When you use this option, Jenkins also lets you specify a label, which will restrict the use of this installation to the build notes with this label. This is a useful technique if you need to install a specific version of a tool on certain build machines. The same approach can also be used for other build tools (such as Maven and Ant).
The automatic installer will not work in all environments (if it can’t find or identify your operating system to its satisfaction, for example, the installation will fail), but it is nevertheless a useful and convenient way to set up new build servers or distributed build agents in a consistent manner.