Java : d’où ça vient, pourquoi c’est comme ça

Université de Toulon

LIS UMR CNRS 7020

2026-10-31

Bien des aspects de Java surprennent quand on les rencontre sans contexte : l’absence de surcharge d’opérateurs, l’héritage multiple interdit, les exceptions que le compilateur vous impose de traiter, ou encore ce réflexe de tout faire passer par une machine virtuelle. Cette leçon soutient une thèse simple : rien de tout cela n’est une excentricité. Chaque particularité est la trace d’un arbitrage posé au début des années 1990, dans des contraintes précises. Comprendre ces arbitrages, c’est déjà apprendre à lire le langage.

1991 : le projet Green et l’électronique embarquée

1991, projet « Green » (Sun Microsystems, James Gosling) : technologie pour appareils électroménagers intelligents.
Constat : C et C++ inadaptés à cette cible embarquée.
Contraintes fondatrices : matériel hétérogène et limité, machines en réseau, robustesse sans maintenance.
1995 : lancement officiel ; la JVM fait du langage un acteur majeur du web naissant.
Thèse de la leçon : les « bizarreries » de Java sont les fossiles de ces contraintes.

Concevoir contre C++ : des arbitrages, pas des excentricités

Surcharge d’opérateurs — abandonnée : prix = pas de notation infixée ; gagné = appels toujours lisibles.
Héritage multiple de classes — refusé : prix = hiérarchies uniques ; gagné = pas de conflit du diamant (deux ancêtres qui se recouvrent), cohérent avec « préférer la composition ».
Ramasse-miettes : prix = pauses, libération non prévisible ; gagné = disparition de la libération manuelle (plus de pointeurs pendillants ni de doubles libérations) ; la rétention involontaire de mémoire reste possible.
Exceptions checkées : prix = verbosité ; gagné = les échecs prévisibles sont déclarés dans la signature et imposés par le compilateur.
Lecture juste : chaque choix est un échange, jamais une interdiction gratuite.

1995 et le pari de la JVM

Le pari : ne pas porter le compilateur, porter la machine.
Deux artefacts : bytecode .class (spécification unique) + JVM (une implémentation par OS).
Formule : « compiler une fois, exécuter partout ».
Prix : pas d’exécution native directe → rattrapé par la JIT (et l’AOT).
Bonus : la JVM vérifie le bytecode, borne la sécurité, accueille d’autres langages.

Sunrise, Oracle, 2010 : la guerre des licences

2006 : Sun ouvre l’implémentation sous GPL → OpenJDK, base des implémentations libres.
2010 : Oracle rachète Sun (nom de code « Sunrise ») et acquiert Java.
Ambiguïté : code source ouvert, binaires Oracle sous licence propriétaire.
Réponse de l’écosystème : AdoptOpenJDK → Eclipse Temurin, binaires libres (notre choix de cours).
Effet annexe : Java EE passe à l’Eclipse Foundation, javax.* devient jakarta.*.

Le train des versions

Depuis 2017 : une version tous les six mois (mars / septembre) ; les intermédiaires (22, 23…) vivent six mois.
LTS : 8 (2014), 11 (2018), 17 (2021), 21 (2023, support 2028), 25 (2025, support 2030).
Pourquoi une LTS pour un projet : fenêtre de correctifs longue, chaîne d’outils stable, pas de migration semestrielle.
Conséquence observable : le parc (stages, entreprises) reste en retard sur le langage.
Choix du cours : Java 25 LTS.

Le cadre technique qui en découle

JVM : exécute le bytecode. JRE : exécution seule (historique). JDK : JVM + javac + outils — notre exigence.
Vérification réflexe : java --version et javac --version → version 25 ou supérieure.
Installation : guidée dans la séance « Mise en œuvre de Java » (Temurin, SDKMan, JAVA_HOME).
Baseline du cours : Java 25 LTS.

Ce que vous retiendrez

Thèse : la syntaxe de Java est un document historique — chaque bizarrerie est un arbitrage hérité de 1991-1995.
JVM et bytecode → vécus en TP mécanique.
Ramasse-miettes → vécu en Bases.
Exceptions checkées → vécues en JDBC+exceptions.
Pas d’héritage multiple → vécu en Réutilisation/composition.
Train des versions → vécu en Bases+record (syntaxes récentes absentes de Java 8).
Licences et distributions → vécues en Histoire 2014-25.
Baseline de travail : Temurin + SDKMan + Java 25 LTS.