Historiquement, l'une des utilisations les plus communes de Jenkins était de construire des applications Java. Jenkins fournit donc naturellement un support intégré pour Java.

Par défaut, Jenkins construira les applications Java en utilisant la version de Java qu'il trouve dans le PATH, qui est habituellement celle avec laquelle Jenkins fonctionne. Toutefois, pour un serveur de build de production, vous voudrez probablement plus de contrôle que cela. Par exemple, vous pourriez exécuter votre serveur Jenkins avec Java 6, pour des raisons de performance. Par contre, votre serveur de production pourrait tourner avec Java 5 ou même Java 1.4. Les grosses organisations sont souvent très précautionneuses lorsqu'il s'agit de mettre à jour les versions de Java dans leurs environnements de production, et certains des serveurs d'application poids-lourds du marché sont de notoriété publique lents à être certifiés avec les derniers JDKs.

Dans tous les cas, c'est toujours une sage pratique que de construire votre application en utilisant une version de Java proche de celle utilisée sur votre serveur de production. Bien qu'une application compilée avec Java 1.4 tournera généralement avec Java 6, l'inverse n'est pas toujours vrai. Vous pourriez aussi avoir plusieurs applications qui nécessitent d'être construites avec différentes versions de Java.

Jenkins fournit un bon support pour travailler avec de multiples JVMs. En effet, Jenkins rend très facile la configuration et l'utilisation de plusieurs versions de Java. Comme la plupart des configurations de niveau système, cela se paramètre dans l'écran Configurer le système (voir Figure 4.2, “Configuration du système dans Jenkins”). A cet endroit, vous trouverez une section appelée JDK qui vous permettra de gérer les installations de JDK avec lesquelles vous voulez que Jenkins travaille.

Le moyen le plus simple de déclarer une installation de JDK est de fournir un nom approprié (qui sera ensuite utilisé pour identifier cette installation de Java lors de la configuration de vos builds), et un chemin vers le répertoire de l'installation Java (le même chemin que vous utiliseriez pour la variable JAVA_HOME), comme montré sur Figure 4.5, “Configuration des JDKs dans Jenkins”. Bien que vous deviez entrer le chemin manuellement, Jenkins vérifiera en temps réel à la fois que le répertoire existe et que ça ressemble à un répertoire JDK valide.

Vous pouvez aussi demander à Jenkins d'installer Java pour vous. Dans ce cas, Jenkins téléchargera l'installeur du JDK et installera une copie sur votre machine (voir Figure 4.6, “Installer un JDK automatiquement”). La première fois qu'une construction a besoin d'utiliser ce JDK, Jenkins téléchargera et installera la version spécifiée de Java dans le répertoire tools du répertoire racine de Jenkins. Si le build est exécuté sur un nouvel agent de build qui n'a pas ce JDK installé, il le téléchargera et l'installera sur celui-ci de la même façon.

C'est aussi un formidable moyen de configurer les agents de construction. Comme nous le verrons plus loin dans le livre, Jenkins peut déléguer des tâches de build à d'autres machines, ou d'autres agents de construction. Un agent de construction (ou “esclave”) est simplement un autre ordinateur que Jenkins peut utiliser pour exécuter certains de ses builds. Si vous utilisez l'option d'installation automatique de Jenkins, vous n'avez pas à installer toutes les versions du JDK dont vous avez besoin sur les machines agent de construction — Jenkins le fera pour vous la première fois que cela lui sera nécessaire.

Par défaut, Jenkins propose de télécharger le JDK à partir du site web d'Oracle. Si votre installation Jenkins est derrière un serveur proxy, vous pourrez avoir besoin de modifier votre configuration de proxy pour permettre à Jenkins d'accéder aux sites externes de téléchargement (voir Section 4.9, “Configurer un Proxy”). Une autre option est de fournir une URL pointant sur votre propre copie interne des binaires du JDK (soit sous la forme d'un ZIP soit sous la forme d'un fichier TAR compressé avec GZip), stocké sur un serveur local à l'intérieur de votre organisation. Cela vous permet de fournir des installations normalisées sur un serveur local et d'accélérer les installations automatiques. Quand vous utilisez cette option, Jenkins vous permet aussi de spécifier un label, ce qui resteindra l'utilisation de cette installation aux noeuds ayant ce label. C'est une technique utile si vous avez besoin d'installer une version spécifique d'un outil sur certaines machines de build. La même approche peut aussi être utilisée pour les autres outils de build (comme Maven et Ant).

L'installeur automatique ne fonctionnera pas dans tous les environnements (s'il ne parvient pas à trouver ou identifier un système d'exploitation satisfaisant, par exemple, l'installation échouera), mais c'est néanmoins un moyen utile et agréable de configurer de nouveaux serveurs de build ou des agents de construction distribués de manière consistante.