Introduction
Le cycle de six mois, les versions à support long terme, et l'inférence de type local.
Ce que Java a gagné depuis la version 8
Vous ouvrez un dépôt récent et le code ne ressemble plus à celui que vous écriviez. Une classe tient en une ligne et n'a ni champ ni accesseur visible. Un switch renvoie une valeur au lieu d'affecter une variable, et il n'y a aucun break. Une déclaration commence par var sans que le type apparaisse nulle part. Une chaîne SQL s'étale sur douze lignes sans une seule concaténation. Rien de tout cela n'est une bibliothèque tierce : c'est du Java standard, arrivé entre la version 9 et la version 21, pendant que votre application restait sur la 8.
Le problème concret n'est pas esthétique. Il est budgétaire et opérationnel. Java 8 n'est plus corrigé gratuitement par la plupart des distributions ; votre image Docker embarque une machine virtuelle dont les correctifs de sécurité sont désormais payants ou inexistants. Les bibliothèques que vous utilisez publient des versions majeures qui exigent Java 17 au minimum : Spring Boot 3, Hibernate 6, les pilotes de bases de données récents. Chaque mois passé sur la 8 augmente le coût de la migration, parce que vous accumulez du retard sur trois fronts en même temps : la plateforme, les dépendances, et les habitudes d'écriture de votre équipe.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion