Installer Java 8 sur Ubuntu - Le guide DevOps pour un environnement stable

Pourquoi Java 8 reste encore utile dans un environnement DevOps

Je ne conseille pas Java 8 pour une nouvelle base de code, mais je le vois encore partout dans des systèmes qui ont vécu. Dans la pratique, il reste présent pour des applications legacy, des plugins Maven anciens, des agents de supervision, des builds qui doivent reproduire un comportement historique ou des conteneurs déjà validés en production.

Le point important, c’est que le besoin n’est presque jamais théorique. Il vient d’une contrainte de compatibilité, parfois d’un fournisseur logiciel, parfois d’un environnement de déploiement qui n’a pas encore migré vers 17 ou 21. Dans ce contexte, forcer une montée de version sans préparation casse plus de choses qu’elle n’en résout.

Je garde donc une règle simple : Java 8 peut encore être un bon choix de transition, mais jamais un bon point de départ. Si vous devez le conserver, il faut surtout le rendre reproductible et maîtrisé. C’est justement pour ça que le choix de la méthode d’installation compte autant que la commande elle-même.

Quelle méthode choisir sur Ubuntu

Avant de taper la moindre commande, je regarde toujours le niveau de contrôle que je veux sur la machine. Sur Ubuntu, deux voies sont vraiment utiles : le paquet fourni par la distribution et le dépôt Temurin d’Adoptium. Le premier est simple quand il existe ; le second est souvent plus stable dans les contextes de build, de serveur ou de conteneur.

Si vous êtes sur une machine personnelle, le paquet Ubuntu est souvent le chemin le plus court. Si vous préparez un serveur, un runner CI ou une image Docker, je préfère généralement Temurin, parce que la reproductibilité vaut plus qu’un gain de quelques secondes à l’installation. Une fois la stratégie choisie, l’installation elle-même devient très simple.

Installer le JDK 8 depuis les dépôts Ubuntu

Sur les versions récentes d’Ubuntu qui exposent encore ce paquet, l’installation la plus directe ressemble à ceci :

sudo apt update
sudo apt install openjdk-8-jdk
java -version
javac -version

Je recommande le JDK et pas seulement le runtime, parce qu’un environnement DevOps ne sert pas uniquement à exécuter une application. Il sert aussi à compiler, tester, empaqueter et parfois générer des artefacts dans une chaîne automatisée. Le JRE peut suffire sur une machine d’exécution très minimale, mais dès qu’il y a du build, il devient vite trop court.

Passer par Temurin 8 quand il faut une base plus stable

Temurin est, de mon point de vue, la solution la plus propre quand on veut une installation Java 8 portable entre plusieurs machines Ubuntu ou dans un pipeline. Le paquet porte un nom clair, temurin-8-jdk, et la logique d’installation reste la même qu’avec les autres paquets DEB. L’intérêt principal, c’est la cohérence : la version installée, les chemins, et le comportement du runtime sont plus faciles à standardiser.

sudo apt install -y wget apt-transport-https gpg
wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/adoptium.gpg > /dev/null
echo "deb https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print $2}' /etc/os-release) main" | sudo tee /etc/apt/sources.list.d/adoptium.list
sudo apt update
sudo apt install temurin-8-jdk
java -version
javac -version

Je préfère cette voie dès qu’il faut préparer des machines identiques, parce que le dépôt dédié évite les écarts entre environnements. La clé GPG n’est pas un détail décoratif : elle permet de garder une chaîne d’approvisionnement logicielle plus propre, ce qui compte encore plus sur un serveur partagé ou dans un contexte de production. Une fois le JDK installé, le vrai sujet devient la version réellement utilisée par le système et par vos outils de build.

Définir la version par défaut et la variable JAVA_HOME

Le piège classique, c’est d’installer Java 8 puis de découvrir que le terminal, Maven ou Gradle continue d’utiliser une autre version. C’est normal : update-alternatives gère les liens système, alors que JAVA_HOME sert de référence à beaucoup d’outils Java. Les deux doivent être cohérents.

Pour choisir la version active, je passe d’abord par les alternatives du système :

sudo update-alternatives --config java
sudo update-alternatives --config javac

Ensuite, je vérifie le chemin du JDK réellement installé :

readlink -f "$(which javac)"
ls /usr/lib/jvm

Sur OpenJDK 8, le répertoire ressemble souvent à /usr/lib/jvm/java-8-openjdk-amd64 sur une machine amd64, mais je préfère toujours vérifier plutôt que supposer. Avec Temurin, le nom du dossier change, donc un copier-coller aveugle peut créer un faux sentiment de sécurité.

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export PATH="$JAVA_HOME/bin:$PATH"

Si vous travaillez avec Maven, Gradle, Jenkins, GitLab CI ou un script shell maison, JAVA_HOME doit être défini dans l’environnement qui exécute le build, pas seulement dans votre session interactive. C’est souvent ce détail qui sépare une installation “qui marche chez moi” d’un environnement réellement fiable. Une fois ce verrou posé, il reste à éliminer les erreurs que je vois le plus souvent sur les serveurs et les pipelines.

Les pièges que je vois le plus souvent sur les serveurs et les pipelines

Quand une installation Java 8 pose problème, le souci n’est pas toujours le paquet lui-même. Voici les cas qui reviennent le plus souvent dans les environnements DevOps :

• Le JRE a été installé au lieu du JDK : la machine exécute l’application, mais ne peut pas la compiler.
• java et javac pointent vers des versions différentes : le build devient incohérent, surtout avec Maven ou Gradle.
• JAVA_HOME n’est pas défini : certains outils se rabattent sur une autre version déjà présente sur le système.
• Le paquet Ubuntu n’existe pas sur cette version : dans ce cas, Temurin est plus propre qu’une installation manuelle bricolée.
• Java 8 est activé globalement sur une machine partagée : un autre projet peut casser silencieusement si vous ne segmentez pas les contextes.

Mon réflexe, dans ce genre de situation, est simple : je vérifie d’abord java -version, puis javac -version, puis la valeur de JAVA_HOME. Si ces trois points ne racontent pas la même histoire, il y a déjà une cause probable. Et si la machine sert plusieurs projets, je préfère isoler Java 8 par projet ou par pipeline plutôt que de l’imposer partout.

Garder Java 8 sous contrôle sans bloquer la suite

Le bon usage de Java 8 aujourd’hui, ce n’est pas de l’installer une fois et d’oublier le sujet. C’est de le rendre reproductible, traçable et limité à ce qui en a réellement besoin. Dans un pipeline, je conseille de figer la version du JDK, de documenter la raison de ce choix et de séparer clairement la phase de build de la phase d’exécution.

• Dans Docker, partez d’une image Java 8 dédiée et taggée explicitement.
• Dans CI/CD, définissez JAVA_HOME et PATH au niveau du job.
• Sur un serveur, gardez le nombre de JDK installés au strict nécessaire.
• Si le projet vit encore longtemps, ouvrez dès maintenant un chantier de migration vers 17 ou 21.

Je résume ma position de façon très concrète : installer Java 8 sur Ubuntu est facile, mais garder un environnement stable autour de cette version demande de la discipline. C’est ce cadre qui évite les builds qui changent de comportement d’un serveur à l’autre, et c’est aussi ce qui prépare une migration propre lorsque le projet sera prêt.