# ADR-0002: Java 17 LTS statt Java 21

* Status: Angenommen
* Datum: 2026-08-17 (nachträglich dokumentiert; Entscheidung war bereits mit dem ersten Commit
  wirksam)

## Kontext und Problemstellung

Zum Projektstart war sowohl Java 17 LTS als auch das neuere Java 21 LTS verfügbar. Das
Nachbarprojekt `library-enterprise-platform` in derselben Lernumgebung nutzt bereits
Java 21. Es musste entschieden werden, ob PROCUREX dieselbe Version übernimmt oder bewusst bei
Java 17 bleibt.

## Entscheidungstreiber

* Spring Boot 3.3.4 (siehe ADR-Kontext Seite 08) unterstützt beide Java-Versionen.
* Der geteilte Jenkins-Controller in `enterprise-infrastructure` bringt eine feste Werkzeugausstattung mit; ein
  Versionswechsel sollte begründet sein, nicht automatisch der neuesten Version folgen.
* Lernziel: bewusst nachvollziehen, wann eine Java-Versionsentscheidung sich lohnt und wann nicht,
  statt reflexhaft „immer die neueste LTS“ zu wählen.

## Betrachtete Optionen

* Java 21 LTS, identisch zum Nachbarprojekt.
* Java 17 LTS, eine Version älter, aber ebenfalls LTS mit Langzeitsupport.

## Entscheidung

Java 17 LTS. `maven.compiler.release=17` im Parent-POM (`pom.xml`), unabhängig von der im
Nachbarprojekt getroffenen Wahl.

## Begründung

* Java 17 deckt alle von PROCUREX genutzten Sprachfeatures ab (Records, Pattern Matching für
  `instanceof`, Sealed Classes) — Java 21 bringt für dieses Projekt keine Pflichtfeatures wie
  virtuelle Threads, die hier aktiv genutzt würden.
* Bewusste Abgrenzung zum Nachbarprojekt: zwei unterschiedliche, aber beide unterstützte
  LTS-Versionen im selben geteilten Jenkins zu betreiben ist ein realistisches Szenario in
  gewachsenen Unternehmensumgebungen und wird hier absichtlich geübt statt vereinheitlicht.
* Kein technischer Zwang zur Angleichung, da Module unabhängig gebaut werden und der
  Jenkins-Controller keine global fixierte Java-Version voraussetzt (anders als bei der
  Node-Version, siehe ADR zu Docker-Build-Agents in `Jenkinsfile`).

## Konsequenzen

* Positiv: kein Migrationsaufwand, falls das Nachbarprojekt seine Java-Version ändert.
* Negativ: PROCUREX profitiert nicht von Java-21-Verbesserungen (z. B. virtuelle Threads für
  E/A-lastige Endpunkte), sollte das später relevant werden, wäre eine neue ADR nötig.
* Der `maven-enforcer-plugin`-Check im `quality-gates`-Profil erzwingt lediglich „Java 17 oder
  neuer“ (`requireJavaVersion: [17,)`), nicht exakt 17 — ein Fehlgriff auf einer neueren
  Runtime würde also nicht durch den Enforcer verhindert, nur durch `maven.compiler.release`.

## Weitere Informationen

Siehe Confluence Seite 08 „Technologie und Frameworks“ (CONFIRMED) sowie `pom.xml`, Zeilen
16–23.