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

Emmanuel BRUNO
emmanuel.bruno@univ-tln.fr

Université de Toulon

LIS UMR CNRS 7020

2026-11-09

Bien des aspects de Java surprennent même après une première vue d’ensemble : 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. Le vocabulaire objet — classe, objet, attribut, message, encapsulation — ainsi que la spécialisation et le polymorphisme, UML en bref et un panorama de langages, et une première vue d’ensemble de Java (ses caractéristiques, l’outillage minimal) ont été posés dans la première séance, « Le paradigme objet » (00_java_L_paradigme_objet.qmd) ; cette seconde séance explique pourquoi Java ressemble à ce qu’il est.

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 (compilation à chaud) et l’AOT (compilation anticipée).
  • Bonus : la JVM vérifie le bytecode à son chargement, d’où une exécution contrôlée, et accueille d’autres langages.

La figure ci-dessous résume cette chaîne d’exécution, du source .java au bytecode .class accueilli par la JVM.

Figure 1: La chaîne javac, bytecode, JVM

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.*.

La figure ci-dessous retrace la chronologie de ces épisodes de licence, de l’ouverture GPL de 2006 au renommage jakarta.*.

Figure 2: Chronologie des licences Java

Le train des versions

  • Depuis 2017 : une version tous les six mois (mars / septembre) ; les intermédiaires (22, 23…) vivent six mois.
  • LTS (Long-Term Support) : 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 au moment de la rédaction.
  • Installation : guidée dans la séance « Mise en œuvre de Java » (Temurin, SDKMan, JAVA_HOME).
  • Baseline du cours : Java 25 LTS.

La figure ci-dessous illustre l’emboîtement de ces trois périmètres.

Figure 3: Emboîtement JDK, JRE, JVM

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 — La mécanique Java, à la main ».
  • 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 dans cette leçon, section versions et LTS.
  • Baseline de travail : Temurin + SDKMan + Java 25 LTS.