Enterprise Java 11, 17 und 21 - Alles-in-einem Lese- und Referenzbuch

Diese konsolidierte Fassung bündelt die wichtigsten Inhalte des Pakets in einer zentralen Lesedatei. Die Desktop-HTML nutzt das breite PC-Layout aus; die iPhone/Safari-HTML bleibt robust und ohne kritische JavaScript-Abhängigkeit nutzbar.

Lesestrategie

• Für PC: ALLES_IN_EINEM_ENTERPRISE_JAVA_BUCH_PC.html öffnen.
• Für iPhone/iPad/Safari: ALLES_IN_EINEM_ENTERPRISE_JAVA_BUCH_IPHONE_SAFARI.html öffnen.
• Für Druck/Archiv: ALLES_IN_EINEM_ENTERPRISE_JAVA_BUCH_DRUCKFASSUNG.pdf nutzen.

Inhaltliche Landkarte

Java 11/17/21 -> Architektur -> Daten -> APIs -> Messaging -> Testing -> Performance -> Migration -> Framework-Labs -> Referenz -> Code

So nutzt du dieses Lernpaket

Kompakte Abschluss-Landkarte für das Enterprise-Java-11/17/21-Lese- und Referenzbuch.

Was dich erwartet

Diese Abschlussversion ist als Lese- und Referenzbuch gedacht: Du kannst sie wie ein Buch lesen, aber auch wie eine Nachschlageplattform verwenden. Die vorherigen Ausbaustufen bleiben nicht als Archiv herumliegen, sondern sind inhaltlich als Lernschichten im Gesamtpaket integriert.

Die finale Politur konzentriert sich auf Orientierung, saubere Öffnungsreihenfolge, bessere Portal-Navigation, kompaktere PDF-Führung, zusätzliche Praxisübungen und nachvollziehbare Abschlusschecks.

Empfohlene Öffnungsreihenfolge

Für PDF-Lesen ist die beste Reihenfolge: Portal-Handbuch, dann Masterbuch, dann Version-2/3/4-PDFs nach Bedarf.

Was fachlich enthalten ist

Das Paket behandelt Java 11, Java 17 und Java 21 aus Enterprise-Sicht. Der Schwerpunkt liegt nicht auf isolierten Sprachfeatures, sondern auf der Frage: Wie baut, modernisiert, prüft und betreibt man Enterprise-Java-Systeme?

Wichtige fachliche Blöcke:

• Java-LTS-Vergleich und Migration von älteren Codebasen.
• Enterprise-Architektur mit Layering, Hexagonal Architecture und DDD-Aggregaten.
• REST, DTOs, Fehlerbehandlung, Security und Observability.
• JPA/Hibernate, Transaktionen, Locking und Datenzugriff.
• Messaging, Outbox Pattern, Events und Integrationsflüsse.
• Performance, JVM-Basics, Virtual Threads und Java-21-Nebenläufigkeit.
• Framework-Orientierung: Spring Boot, Jakarta EE, Quarkus und Micronaut.

Was technisch enthalten ist

Das Paket enthält mehrere Code-Labs. Die wichtigsten sind:

Die Framework-Adapter enthalten bewusst Spring/Jakarta/Quarkus/Micronaut-Importe. Diese sind als Projektstruktur und Lerncode enthalten; ein echter Build benötigt Maven und Internetzugriff auf Repositories.

Entwurfsmuster im Paket

Entwurfsmuster sind im Code nicht versteckt, sondern bewusst markiert. Zusätzlich liegen in den jeweiligen docs/design-patterns.md und docs/design-patterns.html Dateien Beschreibungen mit Pattern, Zweck, Einsatzort und Begründung.

Besonders wichtig:

• Repository Pattern für Datenzugriff hinter Ports.
• Ports and Adapters / Hexagonal Architecture für Framework-Unabhängigkeit.
• Strategy Pattern für austauschbare Preis-/Risiko-/Entscheidungslogik.
• Factory Pattern für kontrollierte Erzeugung von Entscheidungen oder Domänenobjekten.
• Facade Pattern für lesbare Query- oder API-Zugänge.
• Outbox Pattern für robuste Event-Veröffentlichung nach Transaktionen.
• Saga / Process Manager im Framework-Core für mehrstufige Fulfillment-Flows.

Praxisübungen für die nächste Lernrunde

Die Übungen sind bewusst nicht als neues Großprojekt angelegt, sondern als Aufgaben, die du mit dem vorhandenen Material lösen kannst.

Übung 1: Lies den Order-Fulfillment-Flow im Core und zeichne ihn als eigene Sequenz.
Übung 2: Finde im Code alle Ports und Adapter und ordne sie fachlich zu.
Übung 3: Erweitere Money um eine Rundungsregel und prüfe Auswirkungen.
Übung 4: Baue eine neue PricingStrategy ein und dokumentiere das Pattern.
Übung 5: Erweitere das Runtime-Lab um eine neue RuntimeLine.
Übung 6: Schreibe einen ADR-Entwurf für Java 17 vs Java 21.
Übung 7: Beschreibe, welche Dateien du für einen echten Spring-Boot-Start zuerst anfassen würdest.
Übung 8: Erstelle eine Migration-Checkliste von Java 8 auf Java 21.

Die ausführlichere Übungssammlung liegt in referenz/leseplan-und-praxisuebungen.html.

PDF- und HTML-Hinweise

Die HTML-Dateien sind offline-fähig, verwenden lokale CSS-/JS-Dateien und sind auch ohne JavaScript grundsätzlich lesbar. JavaScript wird nur für Komfortfunktionen wie Suche, Treffer-Navigation, Copy-Button und Auf-/Zuklappen verwendet.

Die PDFs sind als Lesefassungen gedacht. Das finale Portal-PDF hat bewusst ein kurzes sichtbares Inhaltsverzeichnis, damit der Einstieg nicht von zu vielen Unterpunkten überladen wird. Für vollständige Navigation ist HTML besser geeignet.

Abschlussstatus

Die finale Prüfung umfasst:

• lokale HTML-Linkprüfung ohne externe Links,
• Vorhandensein der zentralen Startdateien,
• Renderprobe des finalen Portal-PDFs,
• javac --release 21 für JDK-only Labs,
• Demo-Runs der prüfbaren Labs,
• Manifest, SHA-256-Checksummen und ZIP-Test.

Details stehen in checks/CHECK_FINAL.html und checks/CHECK_ZIP.html.

Leseplan und Praxisübungen

Übungen, Lernrouten und kleine Arbeitsaufträge für das Enterprise-Java-Paket.

Lernrouten

12 kompakte Praxis-Sprints

Konkrete Code-Aufgaben

// Aufgabe: Neue Preisstrategie ergänzen
// Pattern: Strategy Pattern - austauschbare Berechnungsregel
public final class VipPricingPolicy implements PricingPolicy {
    @Override
    public Money calculate(Order order) {
        return order.total().discountPercent(10);
    }
}

Aufgabe: Dokumentiere danach in docs/design-patterns.md:
- Pattern: Strategy Pattern
- Zweck: Preislogik austauschbar machen
- Einsatzort: PricingPolicy / VipPricingPolicy
- Begründung: keine if/else-Kaskade im Use Case

Architektur-Aufgaben

[REST Adapter] -> [Use Case] -> [Domain Model]
      |              |              |
      v              v              v
 [DTO Mapper]   [Ports]       [Events]
                    |
                    v
          [Repository / Gateway Adapter]

Arbeite heraus:

• Welche Klassen gehören zum Kern?
• Welche Klassen sind technische Adapter?
• Wo dürfen Framework-Annotationen vorkommen?
• Welche Abhängigkeiten wären in einem echten Projekt kritisch?

Prüf-Aufgaben

Nutze diese Abschlussfragen:

1. Kannst du den Unterschied zwischen Java 11, 17 und 21 im Enterprise-Kontext erklären?
2. Kannst du begründen, warum der Core frameworkfrei bleiben sollte?
3. Kannst du den Outbox-Flow fachlich und technisch erklären?
4. Kannst du sagen, wo Transaktionen beginnen und enden sollten?
5. Kannst du mindestens fünf verwendete Entwurfsmuster im Code zeigen?
6. Kannst du erklären, warum Framework-Adapter separat geprüft werden?
7. Kannst du eine realistische Upgrade-Reihenfolge für eine Altanwendung formulieren?

Enterprise Java 11-21: Lese- und Referenzbuch

Java 11 Java 17 Java 21 Enterprise Architektur Komplexe Codebeispiele

Dieses Paket ist als Lese- und Referenzbuch gebaut: Es erklärt die wichtigsten Konzepte verständlich, zeigt technische und fachliche Diagramme, enthält größere Codebeispiele und verweist auf ein kleines Maven-Beispielprojekt. Der Schwerpunkt liegt nicht auf oberflächlichen Featurelisten, sondern auf der Frage: Wie nutzt man Java 11, 17 und 21 sinnvoll in echten Enterprise-Systemen?

Nutzung des Pakets

Starte mit lernweg.html oder index.html. Für längeres Lesen ist die PDF geeignet; für Nachschlagen und Code ist HTML angenehmer. Die einzelnen Themenbücher sind absichtlich getrennt, damit Navigation, Suche und mobile Nutzung übersichtlich bleiben.

Gesamtlandkarte

Landkarte von Java-Versionen zu Enterprise-Praxis

Zielbild des Buchs

Das Buch beantwortet vier zentrale Fragen:

1. Welche Java-Features aus 11, 17 und 21 sind für Enterprise-Systeme wirklich relevant?
2. Wie entwirft man wartbare Architekturen mit klaren Grenzen zwischen API, Anwendung, Domäne und Infrastruktur?
3. Wie sehen komplexere Codebeispiele aus, die nicht nur Spielzeug sind?
4. Wie migriert man ältere Java-8- oder Java-EE-Systeme schrittweise und risikoarm?

Java 11 als stabile Modernisierungsbasis

Java 11 ist für viele Unternehmen der erste große Schritt weg von Java 8. Der Nutzen liegt weniger in spektakulären Sprachfeatures, sondern in der Stabilisierung der Plattform. Man bekommt eine modernere JVM, bessere Container-Erkennung, einen standardisierten HTTP Client und eine Basis, auf der moderne Libraries wieder sinnvoll gepflegt werden können.

Typische Enterprise-Entscheidung: Java 11 zuerst als technische Plattform stabilisieren, ohne sofort alle Architekturentscheidungen umzubauen. Das reduziert Risiko. Erst wenn Build, Tests, Deployment und Observability zuverlässig sind, sollte man größere Refactorings beginnen.

// Java 11: Standard HTTP Client statt alter proprietärer Clients.
// Einsatzort: Adapter zu externem Payment-System.
// Pattern: Adapter Pattern - kapselt das externe HTTP-Protokoll.
HttpClient client = HttpClient.newBuilder()
        .connectTimeout(Duration.ofSeconds(2))
        .build();

HttpRequest request = HttpRequest.newBuilder()
        .uri(URI.create("https://payment.example.test/authorize"))
        .timeout(Duration.ofSeconds(3))
        .header("Content-Type", "application/json")
        .POST(HttpRequest.BodyPublishers.ofString(payload))
        .build();

HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
if (response.statusCode() >= 500) {
    throw new ExternalSystemUnavailableException("Payment temporarily unavailable");
}

Java 17 als moderne Enterprise-LTS-Basis

Java 17 ist im Enterprise-Kontext besonders interessant, weil es moderne Sprachmittel mit LTS-Stabilität verbindet. Records eignen sich sehr gut für unveränderliche DTOs, Value Objects und Query-Projektionen. Sealed Classes helfen bei fachlich geschlossenen Modellbereichen, etwa bei Zahlungsentscheidungen oder Fehlerarten.

// Java 17: Record als unveränderliches DTO.
// Zweck: API-Daten transportieren, ohne versehentliche Mutation.
public record OrderSummaryDto(
        UUID orderId,
        String customerNumber,
        BigDecimal totalAmount,
        String currency,
        String status
) {}

// Java 17: Sealed Interface für kontrollierte fachliche Ergebnisse.
// Pattern: Result Pattern - explizite fachliche Alternativen statt null/Exception-Missbrauch.
public sealed interface PaymentDecision permits Authorized, Rejected, RequiresManualReview {}

public record Authorized(String authorizationId) implements PaymentDecision {}
public record Rejected(String reasonCode, String message) implements PaymentDecision {}
public record RequiresManualReview(String ticketId) implements PaymentDecision {}

Java 21 und moderne Nebenläufigkeit

Java 21 ist für Enterprise-Systeme vor allem wegen Virtual Threads spannend. Viele Geschäftsanwendungen warten sehr häufig auf Datenbank, HTTP, Dateisystem oder Messaging. Virtual Threads können hier ein einfacheres synchrones Programmiermodell ermöglichen. Sie ersetzen aber keine saubere Architektur, keine Pool-Kontrolle und keine Datenbankoptimierung.

Virtual Threads vereinfachen viele blockierende Abläufe, lösen aber keine Datenbankengpässe

// Java 21: Virtual Threads für viele blockierende I/O-Aufgaben.
// Einsatzort: Parallelisierung unabhängiger Lieferantenprüfungen.
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    Future<InventoryResult> inventory = executor.submit(() -> inventoryClient.check(order));
    Future<RiskResult> risk = executor.submit(() -> riskClient.evaluate(order));
    Future<ContractResult> contract = executor.submit(() -> contractClient.validate(order));

    return new PreCheckResult(inventory.get(), risk.get(), contract.get());
}

Architekturprinzip: Ports, Adapter und Domäne

Eine robuste Enterprise-Anwendung trennt nicht nach technischen Schichten allein, sondern nach Verantwortungen. REST Controller, Datenbankzugriff und externe APIs sind Adapter. Die fachlichen Use Cases liegen im Application Core. Das Domain Model enthält Regeln und Invarianten.

Hexagonale Architektur: technische Adapter außen, fachlicher Kern innen

Vorteile:

• Fachliche Logik wird testbar, ohne Webserver oder Datenbank.
• Externe Systeme können ausgetauscht werden.
• Migrationen werden einfacher, weil Adapter einzeln ersetzt werden können.
• Komplexität wird nicht unsichtbar, sondern gezielt eingegrenzt.

// Port im Application Core.
// Pattern: Port and Adapter / Hexagonal Architecture.
public interface PaymentPort {
    PaymentDecision authorize(Order order);
}

// Use Case hängt nur am Port, nicht am konkreten HTTP Client.
public final class PlaceOrderUseCase {
    private final OrderRepository orderRepository;
    private final PaymentPort paymentPort;
    private final OutboxPublisher outboxPublisher;

    public PlaceOrderUseCase(OrderRepository orderRepository,
                             PaymentPort paymentPort,
                             OutboxPublisher outboxPublisher) {
        this.orderRepository = orderRepository;
        this.paymentPort = paymentPort;
        this.outboxPublisher = outboxPublisher;
    }

    public UUID place(PlaceOrderCommand command) {
        Order order = Order.create(command.customerNumber(), command.lines());
        PaymentDecision decision = paymentPort.authorize(order);
        order.apply(decision);
        orderRepository.save(order);
        outboxPublisher.stage(order.pullDomainEvents());
        return order.id();
    }
}

Fachliches Beispiel: Order, Billing und Payment

Die Beispiel-Domäne enthält genug Komplexität, um echte Enterprise-Fragen zu behandeln:

Order Aggregate mit Value Object und Domain Event

Outbox Pattern für zuverlässige Events

Das Outbox Pattern löst ein klassisches Problem: Die Anwendung muss Daten in der Datenbank ändern und gleichzeitig ein Event veröffentlichen. Ohne Outbox kann die Datenbankänderung erfolgreich sein, aber das Event verloren gehen. Mit Outbox wird die Event-Absicht in derselben Datenbanktransaktion gespeichert.

Outbox Pattern: Datenänderung und Event-Absicht in einer Transaktion

// Pattern: Outbox Pattern.
// Zweck: Datenänderung und Event-Publikation zuverlässig entkoppeln.
@Transactional
public UUID placeOrder(PlaceOrderCommand command) {
    Order order = Order.create(command.customerNumber(), command.lines());
    repository.save(order);

    for (DomainEvent event : order.pullDomainEvents()) {
        outboxRepository.insert(OutboxMessage.from(event));
    }
    return order.id();
}

Refactoring einer Monster-Methode

Ein häufiges Legacy-Problem ist eine Methode, die fachliche Regeln, technische Integration, Logging, Transaktionen und Fehlerbehandlung vermischt. Der erste Schritt ist nicht, alles auf einmal neu zu schreiben. Besser ist: Tests ergänzen, Verantwortungen markieren, pure fachliche Logik extrahieren, danach technische Adapter isolieren.

Vorher:

public InvoiceResult processOrder(OrderRequest request) {
    // Validierung, Kundensuche, Rabattberechnung, Payment, Rechnung,
    // Datenbankzugriff, Logging, Retry und Mailversand in einer Methode.
    // Problem: schwer testbar, schwer migrierbar, keine klare Verantwortlichkeit.
    return null;
}

Nachher:

// Pattern: Facade Pattern im Application Service.
// Zweck: extern einfacher Use Case, intern klare Fachschritte.
public InvoiceResult processOrder(OrderRequest request) {
    Order order = orderFactory.createFrom(request);       // Factory Pattern
    pricingService.calculate(order);                      // Domain Service
    PaymentDecision payment = paymentPort.authorize(order); // Port/Adapter
    order.apply(payment);
    Invoice invoice = invoiceService.createInvoice(order);
    outboxPublisher.stage(order.pullDomainEvents());       // Outbox Pattern
    return InvoiceResult.created(order.id(), invoice.number());
}

Datenzugriff: JPA, Transaktionen und Locking

JPA ist mächtig, aber gefährlich, wenn man es als unsichtbare Magie behandelt. Enterprise-Code sollte klar dokumentieren, welche Aggregate geladen werden, wo Transaktionsgrenzen liegen und welches Locking genutzt wird.

// Pattern: Repository Pattern.
// Zweck: fachliche Persistenzschnittstelle statt verstreuter EntityManager-Zugriffe.
public interface OrderRepository {
    Optional<Order> findById(OrderId id);
    void save(Order order);
}

// Beispiel: Optimistic Locking in einer Entity.
@Entity
public class OrderEntity {
    @Id
    private UUID id;

    @Version
    private long version;

    @Enumerated(EnumType.STRING)
    private OrderStatus status;
}

REST APIs und Fehlerverträge

Eine Enterprise-REST-API braucht stabile Verträge. Ein sauberer Fehlervertrag ist wichtiger als viele Endpunkte. Fachliche Fehler sollten für Clients verständlich sein, technische Fehler sollen nicht interne Details leaken.

{
  "errorCode": "PAYMENT_REJECTED",
  "message": "Die Zahlung wurde vom Zahlungsdienst abgelehnt.",
  "correlationId": "6f378c21-0ad7-4cf7-8f1e-d8040f7f9d0a",
  "details": [
    { "field": "paymentMethod", "reason": "CARD_EXPIRED" }
  ]
}

Testing-Pyramide

Testing-Pyramide für Enterprise Java

Gute Tests sind nicht nur viele Tests. Gute Tests liegen auf der richtigen Ebene. Domain-Regeln gehören in schnelle Unit Tests. Datenbank-Mapping, Transaktionen und externe Adapter gehören in Integrationstests. End-to-End-Tests sollen wenige, aber wichtige Geschäftsflüsse absichern.

@Test
void rejectsOrderWhenTotalIsNegative() {
    assertThrows(IllegalArgumentException.class, () ->
        Order.create("C-1000", List.of(new OrderLine("SKU-1", -1, Money.eur("10.00"))))
    );
}

Migration Java 8 zu 11, 17 und 21

Migration von Java 8 nach Java 11, 17 und 21

Eine seriöse Migration sollte in Schritten erfolgen:

1. Build reproduzierbar machen.
2. Tests und Smoke Checks ergänzen.
3. Dependencies aktualisieren.
4. Java 11 als technische Baseline herstellen.
5. Java 17 für moderne Sprache und LTS-Basis einsetzen.
6. Java 21 gezielt für Concurrency-Verbesserungen prüfen.

Referenz: Wann welches Feature verwenden?

Nächste Ausbaustufen

Diese Version ist ein solides Startpaket. Sinnvolle nächste Erweiterungen wären:

• Framework-Bücher zu Spring Boot, Jakarta EE, Quarkus und Micronaut.
• Noch größere Refactoring-Fallstudie mit altem Java-8-Code und modernem Java-17/21-Zielcode.
• Container-Stack mit PostgreSQL, Kafka/Redpanda und Testcontainers.
• Mehr UML-Diagramme und Sequenzdiagramme für echte REST- und Event-Flows.

Java 21 Concurrency und Framework-Integration

Warum dieses Kapitel ergänzt wurde

Java 21 macht Virtual Threads für viele Enterprise-Szenarien interessant. Gleichzeitig darf man Virtual Threads nicht als Ersatz für gute Architektur, Datenbankoptimierung oder Backpressure missverstehen.

Klassischer Fehler

ExecutorService pool = Executors.newFixedThreadPool(50);
for (OrderRequest request : requests) {
    pool.submit(() -> remotePaymentClient.authorize(request));
}

Das Problem ist nicht nur der Threadpool. Das Problem ist häufig die fehlende fachliche Grenze: Payment, Inventory, Invoice und Outbox werden als technische Calls betrachtet statt als kontrollierter Prozess.

Besseres Denkmodell

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var futures = orderIds.stream()
        .map(id -> executor.submit(() -> fulfillmentSaga.fulfill(id)))
        .toList();

    for (var future : futures) {
        future.get();
    }
}

Enterprise-Regeln

Framework-Bezug

Fazit

Virtual Threads sind ein Runtime-Werkzeug. Der fachliche Prozessschnitt bleibt wichtiger als die Thread-Technik.

Migration Java 8 nach 11, 17 und 21

Migration ist ein Risikoprojekt. Man sollte sie nicht mit Feature-Modernisierung, Architekturumbau und Framework-Wechsel gleichzeitig vermischen.

Empfohlener Migrationspfad

Phase 1: Inventarisieren

• Java-Versionen
• Maven/Gradle Plugins
• Frameworks
• Application Server
• Datenbanktreiber
• JAXB/JAX-WS/Jakarta-Abhängigkeiten
• Testabdeckung
• kritische Batchjobs

Phase 2: Java 11 Baseline

Ziel: Anwendung baut, startet und besteht Smoke Tests.

Phase 3: Java 17 Modernisierung

Ziel: Lesbarkeit, DTOs, Result-Typen, klare Fehlerbehandlung.

Phase 4: Java 21 gezielt einsetzen

Ziel: Virtual Threads oder neue Runtime nur dort einsetzen, wo Messdaten Nutzen zeigen.

Refactoring-Beispiel

// Vorher: technische und fachliche Logik vermischt.
if (status.equals("P") && amount.compareTo(BigDecimal.ZERO) > 0 && customer != null) {
    // payment, invoice, mail, db update
}

// Nachher: fachliche Sprache sichtbar.
if (order.isPayable()) {
    paymentWorkflow.authorizeAndInvoice(order);
}

Java 11 Enterprise Referenz

Java 11 ist in vielen Unternehmen die erste realistische Modernisierungsstufe nach Java 8. Das Ziel ist nicht, jede neue Sprachfunktion auszureizen, sondern eine stabile technische Plattform für aktuelle Libraries, moderne Build-Pipelines und bessere Laufzeitdiagnose zu schaffen.

Wichtige Enterprise-Themen

HTTP Client als Adapter

// Pattern: Adapter Pattern.
// Der PaymentHttpAdapter versteckt HTTP-Details vor dem Application Core.
public final class PaymentHttpAdapter implements PaymentPort {
    private final HttpClient client;
    private final URI endpoint;

    public PaymentHttpAdapter(URI endpoint) {
        this.client = HttpClient.newBuilder()
                .connectTimeout(Duration.ofSeconds(2))
                .build();
        this.endpoint = endpoint;
    }

    @Override
    public PaymentDecision authorize(Order order) {
        String payload = PaymentJsonMapper.toJson(order);
        HttpRequest request = HttpRequest.newBuilder(endpoint.resolve("/payments/authorize"))
                .timeout(Duration.ofSeconds(3))
                .header("Content-Type", "application/json")
                .POST(HttpRequest.BodyPublishers.ofString(payload))
                .build();
        try {
            HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
            return PaymentJsonMapper.toDecision(response.body());
        } catch (IOException e) {
            throw new ExternalSystemUnavailableException("Payment I/O failed", e);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new ExternalSystemUnavailableException("Payment call interrupted", e);
        }
    }
}

var richtig verwenden

var ist keine Einladung, Typen zu verstecken. Es ist gut, wenn der rechte Ausdruck den Typ klar macht. Es ist schlecht, wenn fachliche Bedeutung verloren geht.

// Gut: Typ ist rechts klar sichtbar.
var total = Money.eur("42.90");
var customerId = CustomerId.from("C-1000");

// Schlecht: Der Leser muss raten, was load() zurückgibt.
var result = repository.load(id);

Migrationshinweis

Beim Wechsel von Java 8 nach 11 entstehen typische Probleme: entfernte Java-EE-Module, alte JAXB-Abhängigkeiten, alte Bytecode-Bibliotheken, veraltete Maven-Plugins und implizite Classpath-Annahmen. Deshalb sollte ein Migrationsbranch zuerst Build und Tests stabilisieren, bevor Code modernisiert wird.

Java 17 Enterprise Referenz

Java 17 ist für Enterprise-Systeme eine sehr starke Modernisierungsbasis: LTS, moderne Sprache, bessere Lesbarkeit und sinnvolle Modellierungsmöglichkeiten. Besonders wichtig sind Records, sealed types, pattern matching und die Möglichkeit, alte mutable DTOs und unklare Ergebnistypen zu verbessern.

Records für DTOs und Value Objects

// Java 17: unveränderliches Command-Objekt.
public record PlaceOrderCommand(
        String customerNumber,
        List<OrderLineCommand> lines,
        String paymentMethod
) {
    public PlaceOrderCommand {
        if (customerNumber == null || customerNumber.isBlank()) {
            throw new IllegalArgumentException("customerNumber is required");
        }
        lines = List.copyOf(lines);
    }
}

Sealed Classes für fachliche Alternativen

// Pattern: Result Pattern.
// Zweck: fachlich erwartete Alternativen typisiert statt null/Exception.
public sealed interface OrderPlacementResult
        permits OrderPlaced, OrderRejected, OrderRequiresManualReview {
}

public record OrderPlaced(UUID orderId, String invoiceNumber) implements OrderPlacementResult {}
public record OrderRejected(String reasonCode, String message) implements OrderPlacementResult {}
public record OrderRequiresManualReview(UUID orderId, String ticketNumber) implements OrderPlacementResult {}

Switch über fachliche Ergebnisse

public ApiResponse toResponse(OrderPlacementResult result) {
    return switch (result) {
        case OrderPlaced placed -> ApiResponse.created(placed.orderId());
        case OrderRejected rejected -> ApiResponse.badRequest(rejected.reasonCode(), rejected.message());
        case OrderRequiresManualReview review -> ApiResponse.accepted(review.ticketNumber());
    };
}

Enterprise-Regel

Records sind hervorragend für DTOs, Commands und Value Objects. Für JPA-Entities sind klassische Klassen meist weiterhin sinnvoller, weil JPA Identität, Lifecycle, Lazy Loading und Proxies verwaltet.

Java 21 Enterprise Referenz

Java 21 bringt mit Virtual Threads eine besonders wichtige Verbesserung für klassische Enterprise-Anwendungen, die viele blockierende I/O-Aufgaben ausführen. Der wichtigste Punkt: Virtual Threads machen blockierenden Code skalierbarer, aber nicht automatisch richtig.

Klassisches Problem

In vielen Anwendungen blockieren Plattform-Threads beim Warten auf Datenbank, REST APIs oder Dateisystem. Große Threadpools erhöhen Speicherverbrauch und Kontextwechsel. Zu kleine Pools erzeugen Warteschlangen.

Virtual Threads

// Java 21: viele blockierende Tasks mit einfachem synchronen Code.
public final class ParallelPreCheckService {
    public PreCheckResult execute(Order order) {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            var inventory = executor.submit(() -> checkInventory(order));
            var fraud = executor.submit(() -> checkFraud(order));
            var contract = executor.submit(() -> checkContract(order));
            return new PreCheckResult(inventory.get(), fraud.get(), contract.get());
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new PreCheckFailedException("Pre-check interrupted", e);
        } catch (ExecutionException e) {
            throw new PreCheckFailedException("Pre-check failed", e.getCause());
        }
    }
}

Was Virtual Threads nicht lösen

Empfehlung

Virtual Threads zuerst an klar abgegrenzten I/O-Flows testen: parallele externe Checks, Reporting-Aufgaben oder Batch-ähnliche Verarbeitung. Danach Metriken vergleichen: Latenz, Durchsatz, DB-Pool-Auslastung, Fehlerquote und Timeout-Verhalten.

Enterprise Architektur mit Java

Enterprise-Architektur bedeutet nicht, möglichst viele Schichten zu zeichnen. Gute Architektur macht fachliche Regeln sichtbar, technische Abhängigkeiten kontrollierbar und Änderungskosten geringer.

Schichtenmodell und Grenzen

Klassische Layered Architecture ist nützlich, wenn sie diszipliniert umgesetzt wird. Controller dürfen keine Geschäftsregeln enthalten. Repositories dürfen keine fachlichen Entscheidungen treffen. Domain Services dürfen nicht direkt HTTP oder SQL sprechen.

Client
  -> REST Controller
      -> Application Service / Use Case
          -> Domain Model
          -> Ports
              -> Adapter: JPA, HTTP, Kafka

Hexagonale Architektur

Ports und Adapter schützen den fachlichen Kern

Beispielhafte Paketstruktur

com.example.orderbilling
├── order
│   ├── domain
│   ├── application
│   └── adapter
│       ├── rest
│       ├── persistence
│       └── messaging
├── billing
└── shared

Architekturregeln

Anti-Pattern: Anemic Service Blob

Ein häufiger Fehler ist ein riesiger Service, der alle fachlichen Regeln enthält, während Entities nur Datencontainer sind. Besser ist, Invarianten in Aggregate und Value Objects zu verlagern.

Komplexe Codebeispiele

Dieses Kapitel sammelt größere zusammenhängende Beispiele. Die vollständigen Dateien liegen zusätzlich im Ordner code/enterprise-order-billing-demo.

Use Case: Bestellung anlegen

public UUID place(PlaceOrderCommand command) {
    Order order = orderFactory.createFrom(command);
    pricingService.applyPrice(order);
    PaymentDecision decision = paymentPort.authorize(order);
    order.apply(decision);
    orderRepository.save(order);
    outboxPublisher.stage(order.pullDomainEvents());
    return order.id();
}

Ergebnis-Typen statt null

public sealed interface PaymentDecision permits Authorized, Rejected, RequiresManualReview {}
public record Authorized(String authorizationId) implements PaymentDecision {}
public record Rejected(String reasonCode, String message) implements PaymentDecision {}
public record RequiresManualReview(String ticketId) implements PaymentDecision {}

ASCII-Sequenz

Client
  -> OrderController
      -> PlaceOrderUseCase
          -> OrderFactory
          -> PricingService
          -> PaymentPort
              -> PaymentGatewayAdapter
          -> OrderRepository
          -> OutboxPublisher

Maven Enterprise Build und Plugin-Referenz

Maven ist in Enterprise-Java nicht nur ein Build-Tool. Es ist ein Governance-Werkzeug: Dependency-Versionen, Plugin-Versionen, Java-Release, Testphasen, Packaging, Lizenzprüfung und Architekturgrenzen werden reproduzierbar.

Multi-Module Maven als Architekturstütze.

Parent-POM-Regel

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example.enterprisejava</groupId>
  <artifactId>enterprise-platform-parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>

  <properties>
    <maven.compiler.release>21</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencyManagement>
    <dependencies>
      <!-- zentral kontrollierte Versionen -->
    </dependencies>
  </dependencyManagement>
</project>

Wichtige Plugins

Empfehlung

Ein Enterprise-Build sollte fehlschlagen, wenn die Java-Version falsch ist, verbotene Dependencies auftauchen, Tests nicht laufen oder Plugin-Versionen implizit bleiben.

Refactoring-Fallstudie: Java-8-Monster-Methode modernisieren

Dieses Kapitel zeigt eine typische Modernisierung: Aus einer alten Methode mit vielen Verantwortungen entsteht ein klarer Use Case mit Domäne, Ports und Adaptern.

Monster-Methode wird in Verantwortlichkeiten zerlegt.

Ausgangsproblem

public InvoiceResult process(OrderRequest request) {
    if (request == null) throw new IllegalArgumentException("request missing");
    if (request.customerId() == null) throw new IllegalArgumentException("customer missing");
    BigDecimal total = BigDecimal.ZERO;
    for (OrderLineRequest line : request.lines()) {
        if (line.quantity() <= 0) throw new IllegalArgumentException("quantity invalid");
        total = total.add(line.price().multiply(BigDecimal.valueOf(line.quantity())));
    }
    if (request.coupon() != null) total = total.multiply(new BigDecimal("0.90"));
    PaymentResult payment = paymentClient.authorize(request.customerId(), total);
    if (!payment.approved()) return InvoiceResult.rejected(payment.reason());
    long invoiceId = invoiceDao.insert(request.customerId(), total, payment.id());
    eventPublisher.publish("invoice.created", invoiceId);
    mailClient.sendInvoice(invoiceId);
    return InvoiceResult.created(invoiceId);
}

Probleme

Zielstruktur

// Pattern: Facade / Application Service - ein klarer Eingang für den fachlichen Ablauf.
public final class CreateInvoiceUseCase {
    private final OrderValidator validator;
    private final PricingPolicy pricing;
    private final PaymentPort paymentPort;
    private final InvoiceRepository invoiceRepository;
    private final OutboxPort outboxPort;

    public InvoiceResult create(CreateInvoiceCommand command) {
        ValidatedOrder order = validator.validate(command);
        Money total = pricing.calculate(order);
        PaymentDecision decision = paymentPort.authorize(order.customerId(), total);
        Invoice invoice = Invoice.create(order, total, decision);
        invoiceRepository.save(invoice);
        outboxPort.store(new InvoiceCreatedEvent(invoice.id(), total));
        return InvoiceResult.created(invoice.id());
    }
}

Refactoring-Reihenfolge

1. Tests um aktuelles Verhalten legen.
2. reine Berechnungen extrahieren.
3. Ports für externe Systeme einführen.
4. fachliche Ergebnisse explizit modellieren.
5. Datenbanktransaktion und Outbox klären.
6. Controller/API getrennt anpassen.
7. Monitoring und Fehlercodes ergänzen.

Design Patterns im Enterprise-Java-Paket

Diese Datei dokumentiert die verwendeten Entwurfsmuster. Im Maven-Beispielprojekt sind die wichtigsten Pattern zusätzlich direkt im Code kommentiert.

Beispiel: Strategy Pattern

public interface PricingStrategy {
    Money calculate(Order order);
}

public final class EnterpriseCustomerPricing implements PricingStrategy {
    public Money calculate(Order order) {
        return order.rawTotal().minusPercent(10);
    }
}

Datenzugriff, JPA und Transaktionen

Datenzugriff ist einer der häufigsten Orte für versteckte Enterprise-Komplexität. Performanceprobleme, Lazy-Loading-Fehler, falsche Transaktionsgrenzen und Locking-Konflikte entstehen oft nicht durch JPA selbst, sondern durch unklare Verantwortungen.

Repository Pattern

// Pattern: Repository Pattern.
// Zweck: Fachliche Persistenzschnittstelle statt EntityManager überall.
public interface OrderRepository {
    Optional<Order> findById(OrderId id);
    void save(Order order);
    boolean existsOpenOrderForCustomer(CustomerNumber customerNumber);
}

Optimistic Locking

@Entity
@Table(name = "orders")
public class OrderEntity {
    @Id
    private UUID id;

    @Version
    private long version;

    @Enumerated(EnumType.STRING)
    private OrderStatus status;
}

Optimistic Locking ist gut, wenn Konflikte selten sind. Bei hoher Konkurrenz auf denselben Datensatz braucht man andere Strategien: fachliche Reservierungen, Queueing, pessimistische Locks oder eine andere Aggregatgrenze.

Transaktionsgrenzen

Eine Transaktion sollte einen fachlich konsistenten Schritt absichern. Sie sollte nicht unkontrolliert externe HTTP-Aufrufe enthalten. Externe Systeme können hängen, langsam sein oder uneindeutig antworten. Deshalb sind Outbox, Saga und Retry-Strategien in Enterprise-Systemen wichtig.

N+1 Problem

// Problematisch: viele Lazy Loads in einer Schleife.
for (Order order : orderRepository.findAllOpen()) {
    System.out.println(order.customer().name());
}

Besser sind klare Queries, Fetch Joins, Projektionen oder Query-Modelle.

REST API Design für Enterprise Java

REST APIs sind Verträge. Ein guter Vertrag bleibt stabil, auch wenn interne Klassen, Datenbanktabellen oder Frameworks gewechselt werden.

DTO statt Entity Leak

public record CreateOrderRequest(
        String customerNumber,
        List<CreateOrderLineRequest> lines,
        String paymentMethod
) {}

public record CreateOrderResponse(
        UUID orderId,
        String status,
        List<LinkDto> links
) {}

Fehlervertrag

public record ApiError(
        String errorCode,
        String message,
        String correlationId,
        List<FieldError> details
) {}

API Versionierung

Controller dünn halten

// Pattern: Facade über Application Service.
// Controller übersetzt HTTP, entscheidet aber keine Fachregeln.
public CreateOrderResponse create(CreateOrderRequest request) {
    PlaceOrderCommand command = mapper.toCommand(request);
    OrderPlacementResult result = placeOrderUseCase.place(command);
    return mapper.toResponse(result);
}

Messaging, Kafka und Outbox

Event-getriebene Systeme sind nicht automatisch besser. Sie sind besser, wenn man lose Kopplung, Wiederholbarkeit, Idempotenz und Observability sauber behandelt.

Outbox Pattern

Outbox Pattern als Brücke zwischen Datenbanktransaktion und Event-Publishing

Event Design

public record OrderPlacedEvent(
        UUID eventId,
        Instant occurredAt,
        UUID orderId,
        String customerNumber,
        BigDecimal totalAmount,
        String currency
) implements DomainEvent {}

Idempotenter Consumer

// Pattern: Idempotent Consumer.
// Zweck: doppelte Events sicher ignorieren.
public void handle(OrderPlacedEvent event) {
    if (processedEventRepository.exists(event.eventId())) {
        return;
    }
    billingService.createInvoiceFor(event.orderId());
    processedEventRepository.markProcessed(event.eventId());
}

Typische Fehler

Testing für Enterprise Java

Testing ist nicht nur Qualitätssicherung, sondern Architekturwerkzeug. Gute Tests erzwingen klare Grenzen und zeigen, ob Domain, Application und Adapter sauber getrennt sind.

Testing-Pyramide mit Domain-, Integrations- und E2E-Tests

Domain Test

@Test
void orderCannotBePlacedWithoutLines() {
    var command = new PlaceOrderCommand("C-1000", List.of(), "CARD");
    assertThrows(IllegalArgumentException.class, () -> Order.create(command.customerNumber(), command.lines()));
}

Application Test mit Fake Port

// Pattern: Test Double / Fake.
// Zweck: Use Case ohne echtes Payment-System testen.
final class AlwaysAuthorizedPaymentPort implements PaymentPort {
    public PaymentDecision authorize(Order order) {
        return new Authorized("AUTH-1");
    }
}

Integrationstest

Integrationstests prüfen Adapter: JPA-Mapping, SQL, Transaktionen, REST-Serialisierung oder Messaging. Sie sind langsamer, aber unverzichtbar für technische Verträge.

Performance, JVM und Nebenläufigkeit

Performance in Enterprise Java beginnt selten mit Mikrooptimierung. Meist zählen Datenbankzugriffe, Threading, Garbage Collection, Netzwerk, Serialisierung und unnötige Synchronisation.

Diagnose-Reihenfolge

1. Metriken prüfen: Latenz, Durchsatz, Fehler, Sättigung.
2. Logs mit Korrelation auswerten.
3. Datenbankqueries messen.
4. Thread Dumps und Flight Recorder nutzen.
5. Erst dann Code optimieren.

Threadpool vs Virtual Threads

// Klassisch: begrenzter Pool, sinnvoll für CPU-lastige Arbeit.
ExecutorService pool = Executors.newFixedThreadPool(16);

// Java 21: Virtual Threads, sinnvoll für viele blockierende I/O-Aufgaben.
ExecutorService vt = Executors.newVirtualThreadPerTaskExecutor();

JVM-Tuning-Regel

Nicht blind Flags kopieren. Erst messen, dann gezielt ändern. Container-Limits, Heap-Größe, GC-Logs und Response-Time-Ziele müssen zusammen betrachtet werden.

Security in Enterprise Java

Security besteht nicht nur aus Login. Gute Enterprise-Systeme unterscheiden Authentifizierung, technische Autorisierung, fachliche Autorisierung, Audit und Geheimnisverwaltung.

JWT Security Flow.

Authentifizierung vs Autorisierung

Beispiel: fachliche Policy

// Pattern: Policy Pattern - fachliche Berechtigung ist isoliert testbar.
public final class RefundPolicy {
    public boolean mayRefund(UserPrincipal user, Payment payment) {
        if (!user.hasRole("PAYMENT_REFUND")) return false;
        if (!payment.isCaptured()) return false;
        if (payment.isOlderThan(Duration.ofDays(90))) return false;
        return payment.amount().isLessThanOrEqual(user.maxRefundLimit());
    }
}

Typische Fehler

• Nur Rollen prüfen, aber Objektzustand ignorieren.
• Token ungeprüft weiterreichen.
• Secrets in Properties oder Git speichern.
• Audit-Logs ohne Korrelations-ID schreiben.
• Security erst nachträglich in fertige Flows einbauen.

Observability: Logging, Metrics und Tracing

Observability beantwortet Betriebsfragen. Ein Enterprise-System ist nicht fertig, wenn es lokal funktioniert. Es muss im Fehlerfall erklärbar sein.

Observability Pipeline.

Drei Säulen

Strukturierte Logs

// Pattern: Correlation Context - gemeinsame ID für verteilte Analyse.
logger.info("order_placed correlationId={} orderId={} customerId={} amount={}",
        correlationId.value(), order.id(), order.customerId(), order.total());

Gute Metriken

• Latenz pro API und externer Abhängigkeit.
• Fehlerquote nach Fehlerklasse.
• Queue-/Topic-Lag bei Messaging.
• Datenbankverbindungs-Pool-Auslastung.
• Business-Metriken wie Bestellungen pro Minute oder Stornoquote.

Fehlerkatalog Enterprise Java

Dieser Katalog sammelt typische Fehlerbilder, Ursachen und Gegenmaßnahmen.

Architekturfehler

Datenbankfehler

Messagingfehler

Java-21-Fehler

Abschluss-Checkliste

Kompakte Liste für die finale Kontrolle des Enterprise-Java-Pakets.

Abschluss-Checkliste

Was bewusst nicht behauptet wird

Das Paket ist ein Lern- und Referenzpaket. Es ersetzt keine produktive Security-, Lizenz- oder Architekturfreigabe. Externe Framework-Abhängigkeiten wurden nicht vollständig heruntergeladen, weil die lokale Umgebung keinen Maven-Build mit Repository-Zugriff ausführt.

Frameworks, Build, Security und Betrieb

Diese Erweiterung baut auf dem ersten Masterbuch auf. Der Fokus liegt auf Framework-Auswahl, Maven-Struktur, Sicherheitsfluss, Observability, komplexerer Refactoring-Fallstudie und einem erweiterten Java/Maven-Beispielprojekt.

Überblick

Framework-Landkarte

Frameworks haben unterschiedliche Stärken, aber ähnliche Enterprise-Grundprobleme.

Entscheidungsregel

Spring Boot ist oft die pragmatische Standardwahl, wenn Team, Libraries und Betrieb eine breite Plattform brauchen. Jakarta EE ist stark, wenn Standards, Applikationsserver und lange Kompatibilität zentral sind. Quarkus ist interessant bei Cloud-Native, schnellem Start und Kubernetes-Nähe. Micronaut ist attraktiv für schlanke Services, AOT-Ansätze und klare DI-Modelle.

Wichtig ist nicht nur das Framework. Entscheidend ist, ob die Architektur verhindert, dass Controller, Datenbank, Messaging und Domäne zu einem unwartbaren Block verschmelzen.

Maven als Architektur-Werkzeug

Maven-Module erzwingen fachliche Grenzen besser als nur Packages.

Ein Enterprise-Maven-Build sollte nicht nur kompilieren. Er sollte Architekturgrenzen sichtbar machen: Domäne ohne Framework, Anwendung mit Ports, Adapter mit Infrastruktur, Tests mit klaren Schichten.

<modules>
  <module>shared-kernel</module>
  <module>order-domain</module>
  <module>order-application</module>
  <module>adapters</module>
  <module>architecture-tests</module>
</modules>

Spring Boot Request Flow

Ein sauberer Spring Boot Flow hält fachliche Regeln aus dem Controller heraus.

@RestController
@RequestMapping("/orders")
final class OrderController {
    private final PlaceOrderUseCase useCase;

    OrderController(PlaceOrderUseCase useCase) {
        this.useCase = useCase;
    }

    @PostMapping
    ResponseEntity<OrderResponse> place(@Valid @RequestBody PlaceOrderRequest request) {
        PlaceOrderResult result = useCase.place(request.toCommand());
        return ResponseEntity.status(HttpStatus.CREATED)
                .body(OrderResponse.from(result));
    }
}

Jakarta EE Container Flow

Jakarta EE liefert viele Querschnittsfunktionen über Container und Standards.

@Path("/orders")
@RequestScoped
public class OrderResource {
    @Inject
    PlaceOrderService service;

    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    @Produces(MediaType.APPLICATION_JSON)
    public Response place(PlaceOrderRequest request) {
        return Response.status(Response.Status.CREATED)
                .entity(service.place(request.toCommand()))
                .build();
    }
}

Security Flow

JWT löst Authentifizierungstransport, ersetzt aber keine fachliche Autorisierung.

Gute Enterprise-Security trennt vier Ebenen: Identität, technische Zugriffskontrolle, fachliche Berechtigungsregel und Auditierbarkeit. Ein Token sagt nicht automatisch, ob ein Benutzer eine bestimmte Rechnung stornieren darf.

// Pattern: Policy / Specification - fachliche Autorisierung wird testbar und zentral.
public final class CancelInvoicePolicy {
    public boolean mayCancel(UserPrincipal user, Invoice invoice) {
        return user.hasRole("BILLING_ADMIN")
                && invoice.isOpen()
                && !invoice.isExportedToAccounting();
    }
}

Observability

Logs, Metrics und Traces beantworten unterschiedliche Betriebsfragen.

Logs erklären konkrete Ereignisse. Metrics zeigen Trends und SLO-Verletzungen. Traces verbinden mehrere Services zu einer Request-Kette. Ohne Korrelations-ID kann ein verteilter Fehler kaum wirtschaftlich analysiert werden.

// Pattern: Correlation Context - technische Nachvollziehbarkeit über Systemgrenzen.
public record CorrelationId(String value) {
    public static CorrelationId newId() {
        return new CorrelationId(UUID.randomUUID().toString());
    }
}

Refactoring-Fallstudie

Eine Monster-Methode wird in fachliche Verantwortlichkeiten aufgeteilt.

Das Ziel ist nicht, möglichst viele Klassen zu erzeugen. Das Ziel ist, Entscheidungen dort zu platzieren, wo sie fachlich hingehören: Validierung nah am Eingang, Regeln in der Domäne, Orchestrierung im Use Case, Infrastruktur hinter Ports.

// Vorher: technische und fachliche Verantwortung vermischt.
public InvoiceResult process(OrderRequest request) {
    validateRawRequest(request);
    BigDecimal total = calculatePrice(request);
    reserveInventory(request);
    PaymentResult payment = paymentClient.authorize(request.customerId(), total);
    Long invoiceId = jdbc.insertInvoice(request, total, payment.id());
    mailClient.sendInvoice(invoiceId);
    return new InvoiceResult(invoiceId, "CREATED");
}

// Nachher: Use Case orchestriert, Details liegen in spezialisierten Komponenten.
// Pattern: Application Service / Use Case.
public InvoiceResult process(CreateInvoiceCommand command) {
    ValidatedOrder order = validator.validate(command);
    Money total = pricing.calculate(order);
    PaymentDecision decision = paymentPort.authorize(order.customerId(), total);
    Invoice invoice = invoiceFactory.create(order, total, decision);
    invoiceRepository.save(invoice);
    outboxPort.publish(new InvoiceCreatedEvent(invoice.id(), total));
    return InvoiceResult.created(invoice.id());
}

Nächster Lernschritt

Sinnvoll wäre danach eine Version 3 mit noch größeren Framework-spezifischen Beispielprojekten: Spring Boot Runtime, Jakarta EE Variante, Quarkus Runtime, Micronaut Runtime, jeweils mit gleicher Domäne und vergleichbarer Architektur.

Vier Frameworks, eine gemeinsame Domäne

Ziel dieser Ausbaustufe

Version 3 ergänzt das bisherige Lese- und Referenzbuch um eine praktische Vergleichsebene: dieselbe Order-Domäne wird in getrennten Projekten mit Spring Boot, Jakarta EE, Quarkus und Micronaut angebunden. Entscheidend ist nicht, welches Framework schöner aussieht, sondern welche Teile stabil, fachlich und langlebig sind.

Das zentrale Lernprinzip lautet:

Der Enterprise-Core gehört nicht einem Framework. Frameworks sind Adapter, Runtimes und Integrationsumgebungen.

Paketstruktur der Framework-Labs

code/framework-labs/
├── pom.xml
├── order-platform-core/
│   ├── src/main/java/.../domain
│   ├── src/main/java/.../application
│   ├── src/main/java/.../application/port
│   ├── src/main/java/.../adapter
│   └── docs/design-patterns.md
├── spring-boot-order-api/
├── jakarta-ee-order-api/
├── quarkus-order-api/
└── micronaut-order-api/

Warum ein gemeinsamer Core besser ist

Ein häufiger Fehler in Enterprise-Projekten ist, dass Businesslogik direkt in Controller, Resources, Repositories, Entity Listener, Framework Services oder Transaction Scripts wandert. Anfangs fühlt sich das schnell an. Später entsteht Abhängigkeit von Details: Annotationen, Container-Lifecycle, Datenbank-Mapping, HTTP-Struktur, Security-Kontext und Deployment-Modell.

Der gemeinsame Core trennt deshalb bewusst:

Request Flow im Vergleich

Der HTTP-Einstieg unterscheidet sich, aber der Use Case bleibt gleich.

// Kernidee: jeder Adapter erzeugt am Ende denselben Command.
var command = new PlaceOrderCommand(
    new CustomerId(request.customerId()),
    request.lines().stream()
        .map(line -> new PlaceOrderCommand.Line(
            line.sku(),
            line.quantity(),
            Money.eur(line.unitPrice())))
        .toList()
);

var receipt = placeOrderUseCase.place(command);

Spring Boot Lab

Spring Boot wird als Adapterprojekt modelliert. Der Controller ist dünn, Bean-Konfiguration ist bewusst im Adapterprojekt, und die Fehlerbehandlung übersetzt Exceptions in API-Fehler.

@RestController
@RequestMapping("/orders")
public class OrderController {
    private final PlaceOrderUseCase placeOrderUseCase;

    public OrderController(PlaceOrderUseCase placeOrderUseCase) {
        this.placeOrderUseCase = placeOrderUseCase;
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public OrderResponse place(@Valid @RequestBody OrderRequest request) {
        var command = toCommand(request);
        var receipt = placeOrderUseCase.place(command);
        return toResponse(receipt);
    }
}

Spring Boot ist stark, wenn man viel Ökosystem braucht: Actuator, Security, Batch, Integration, Data, Cloud Config, Observability und eine sehr breite Dokumentationsbasis. Die Gefahr ist, dass Fachlogik zu leicht in @Service-Klassen landet, die eigentlich nur Framework-Services statt Use Cases sind.

Jakarta EE Lab

Jakarta EE zeigt ein anderes Betriebsmodell: WAR, Application Server, JAX-RS, CDI und gemanagte Infrastruktur. Das ist besonders relevant, wenn bestehende Java-EE-/Jakarta-EE-Landschaften modernisiert werden, ohne sofort alles in Boot-Anwendungen umzubauen.

@Path("/orders")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class OrderResource {
    @Inject PlaceOrderUseCase placeOrderUseCase;

    @POST
    public Response place(OrderRequest request) {
        var receipt = placeOrderUseCase.place(toCommand(request));
        return Response.status(Response.Status.CREATED)
            .entity(toResponse(receipt))
            .build();
    }
}

Der Lernwert liegt im Container-Verständnis: CDI-Lifecycle, JTA-Grenzen, Security Context, Connection Pools, WAR-Deployment und Unterschiede zwischen fachlicher Transaktion und technischer Container-Transaktion.

Quarkus Lab

Quarkus ist interessant, wenn Container-Nähe, schnelle Startzeiten, geringerer Speicherbedarf und Native-Image-Optionen wichtig werden. Fachlich darf das aber nicht bedeuten, dass der Core Quarkus-spezifisch wird.

@Path("/orders")
public class OrderResource {
    @Inject PlaceOrderUseCase placeOrderUseCase;

    @POST
    public Response place(OrderRequest request) {
        var receipt = placeOrderUseCase.place(toCommand(request));
        return Response.status(201).entity(toResponse(receipt)).build();
    }
}

Das Quarkus-Projekt im Paket zeigt CDI Producer als Composition Root. Dadurch bleibt der Core sauber und Quarkus wird nur an der Grenze sichtbar.

Micronaut Lab

Micronaut legt den Schwerpunkt auf Compile-Time-DI, wenig Reflection und schnelle Starts. Das ist hilfreich für kleinere Services, Serverless-ähnliche Szenarien oder containerisierte Dienste mit vielen Instanzen.

@Controller("/orders")
public class OrderController {
    private final PlaceOrderUseCase placeOrderUseCase;

    public OrderController(PlaceOrderUseCase placeOrderUseCase) {
        this.placeOrderUseCase = placeOrderUseCase;
    }

    @Post
    public HttpResponse<OrderResponse> place(@Body OrderRequest request) {
        var receipt = placeOrderUseCase.place(toCommand(request));
        return HttpResponse.created(toResponse(receipt));
    }
}

Der zentrale Unterschied liegt nicht im fachlichen Code, sondern in DI, HTTP-Stack, Build-Plugins, Runtime-Metadaten und Testunterstützung.

Portabilitäts-Landkarte

Teststrategie für alle vier Frameworks

Die Teststrategie sollte nicht viermal dieselbe fachliche Logik testen. Besser:

1. Core Unit Tests prüfen Businessregeln.
2. Adapter Tests prüfen Mapping, HTTP-Status, Validation und Fehlerformat.
3. Integration Tests prüfen Runtime-Wiring.
4. Contract Tests sichern API-Verträge.
5. Architekturtests prüfen, dass der Core keine Framework-Pakete importiert.

// Beispielregel für einen Architekturtest als Denkmodell:
// classes in ..core.. should not depend on org.springframework.., jakarta.ws.rs..,
// io.quarkus.. or io.micronaut..

Deployment-Formen

Maven- und Build-Regeln

Die Labs verwenden einen Parent-POM. Wichtig ist die Trennung zwischen Lehrbuch-Stabilität und Produktionsrealität.

<modules>
  <module>order-platform-core</module>
  <module>spring-boot-order-api</module>
  <module>jakarta-ee-order-api</module>
  <module>quarkus-order-api</module>
  <module>micronaut-order-api</module>
</modules>

Für echte Projekte sollte man zusätzlich definieren:

• Dependency Management über BOMs
• Enforcer-Regeln für Java-Version, Maven-Version und Dependency-Konvergenz
• SBOM-Erzeugung
• OWASP Dependency Check oder SCA-Werkzeug
• Checkstyle/Spotless
• Architekturtests
• Container-Image-Build
• separate Profile für lokale Entwicklung und CI

Komplexerer Enterprise-Flow

Der Core enthält jetzt nicht nur PlaceOrderUseCase, sondern auch OrderFulfillmentSaga.

public OrderReceipt fulfill(OrderId orderId) {
    var order = repository.findById(orderId)
        .orElseThrow(() -> new IllegalArgumentException("order not found: " + orderId));

    inventoryPort.reserve(order.lines());
    var authorization = paymentGateway.authorize(order.id(), order.total());
    order.authorizePayment(authorization);

    var invoiceNumber = invoicePort.createInvoice(order);
    order.createInvoice(invoiceNumber);
    order.fulfill();

    repository.save(order);
    order.pullEvents().forEach(outboxPort::append);
    return new OrderReceipt(order.id(), order.status(), order.total());
}

Dieses Beispiel ist bewusst nicht als verteilte ACID-Transaktion dargestellt. In echten Systemen wären Kompensationen, Idempotenz, Retry, Outbox, Dead Letter Queue und Monitoring Pflicht.

Was du aus diesem Teil mitnimmst

• Frameworks unterscheiden sich stark in Runtime und Adaptercode.
• Fachliche Modellierung muss davon unabhängig bleiben.
• Maven-Modulgrenzen sind Architekturgrenzen.
• Controller und Resources dürfen nicht zum neuen Monolithen werden.
• Ein gemeinsamer Core macht Migration, Vergleich, Tests und Refactoring einfacher.
• Das richtige Framework hängt von Betriebsmodell, Teamwissen, Plattform, Integrationen und Lebensdauer ab.

Spring Boot im Enterprise-Java-Kontext

Spring Boot ist für viele Enterprise-Teams die pragmatische Standardplattform. Es reduziert Konfiguration, integriert sehr viele Libraries und ermöglicht schnelle Service-Entwicklung. Trotzdem ersetzt Spring Boot keine Architektur. Ohne klare Regeln entstehen schnell Controller mit Geschäftslogik, Services mit SQL-Details und Repositories mit fachlichen Entscheidungen.

Typischer Einsatz

Spring Boot Request Flow mit klarer Trennung.

Gute Schichtenregel

Controller  -> DTO, HTTP, Statuscodes
Use Case    -> fachliche Orchestrierung
Domain      -> Regeln, Zustände, Invarianten
Ports       -> Schnittstellen zu externen Systemen
Adapter     -> JPA, Kafka, REST Clients

Beispiel: Controller bleibt dünn

// Pattern: Adapter Pattern - HTTP wird in einen internen Command übersetzt.
@PostMapping("/orders")
ResponseEntity<OrderResponse> place(@Valid @RequestBody PlaceOrderRequest request) {
    var result = placeOrderUseCase.place(request.toCommand());
    URI location = URI.create("/orders/" + result.orderId());
    return ResponseEntity.created(location)
            .body(OrderResponse.from(result));
}

Typische Fehler

• @Transactional überall verteilen, ohne klare Transaktionsgrenze.
• Entity-Klassen direkt als REST Response ausgeben.
• Business-Entscheidungen in Controller oder Repository verstecken.
• Spring-spezifische Annotationen in die Domäne ziehen.
• Actuator aktivieren, aber keine fachlichen Health Checks definieren.

Empfehlung

Nutze Spring Boot als Infrastrukturplattform. Halte den fachlichen Kern möglichst unabhängig. Dann kann man später einzelne Adapter austauschen, Tests einfacher schreiben und Migrationen kontrollierter durchführen.

Jakarta EE im Enterprise-Java-Kontext

Jakarta EE ist ein Standard-Ökosystem für Enterprise-Java-Anwendungen. Es ist besonders relevant, wenn Organisationen Applikationsserver, langfristige Kompatibilität, standardisierte APIs und klassische Enterprise-Patterns verwenden.

Jakarta EE Container Flow.

Wichtige APIs

Beispiel: CDI Service mit Transaktion

@ApplicationScoped
public class PlaceOrderService {
    @Inject OrderRepository repository;
    @Inject PaymentGateway paymentGateway;
    @Inject EventOutbox outbox;

    @Transactional
    public PlaceOrderResult place(PlaceOrderCommand command) {
        Order order = Order.place(command.customerId(), command.lines());
        PaymentDecision decision = paymentGateway.authorize(order.total());
        order.applyPayment(decision);
        repository.save(order);
        outbox.store(order.pullDomainEvents());
        return PlaceOrderResult.from(order);
    }
}

Stärke

Jakarta EE ist stark, wenn ein Unternehmen Standards gegenüber Framework-spezifischen Konventionen bevorzugt. Besonders bei Legacy-Modernisierung ist Jakarta wichtig, weil viele ältere Java-EE-Anwendungen von hier aus schrittweise modernisiert werden können.

Risiko

Der Container kann zu viel Magie verstecken. Deshalb müssen Transaktionen, Scopes, Lazy Loading und Nebenwirkungen sehr bewusst dokumentiert werden.

Quarkus und Micronaut im Enterprise-Java-Kontext

Quarkus und Micronaut stehen für eine modernere, stärker Cloud-Native-orientierte Sicht auf Java. Beide wollen Startzeit, Speicherverbrauch und Build-Zeit-Verhalten verbessern. Sie sind besonders interessant für Container, Kubernetes, Serverless-ähnliche Workloads und Microservices.

Quarkus und Micronaut im Gesamtvergleich.

Quarkus

Quarkus ist stark in Kubernetes- und Cloud-Native-Szenarien. Es integriert viele bekannte APIs und Extensions. Der Entwicklungsmodus ist sehr produktiv, und das Framework legt Wert auf schnelle Starts und geringe Laufzeitkosten.

@Path("/orders")
public class OrderResource {
    private final PlaceOrderUseCase useCase;

    public OrderResource(PlaceOrderUseCase useCase) {
        this.useCase = useCase;
    }

    @POST
    public Response place(PlaceOrderRequest request) {
        return Response.status(201).entity(useCase.place(request.toCommand())).build();
    }
}

Micronaut

Micronaut ist stark bei compile-time Dependency Injection, leichter Runtime und klarer Testbarkeit. Es eignet sich gut für kleine bis mittlere Services, API-Gateways, Integrationen und Cloud-Funktionen.

@Controller("/orders")
final class OrderController {
    private final PlaceOrderUseCase useCase;

    OrderController(PlaceOrderUseCase useCase) {
        this.useCase = useCase;
    }

    @Post
    HttpResponse<OrderResponse> place(@Body PlaceOrderRequest request) {
        return HttpResponse.created(OrderResponse.from(useCase.place(request.toCommand())));
    }
}

Auswahlregel

Wähle Quarkus, wenn Kubernetes-Nähe, schnelle Starts, Extensions und Java-Cloud-Native im Vordergrund stehen. Wähle Micronaut, wenn compile-time DI, geringer Overhead und sehr klare Service-Strukturen wichtiger sind.

Framework-Labs getrennte Projekte

Überblick

Dieses Themenkapitel erklärt die neue Version-3-Codebasis aus Sicht eines Lesers, der die Dateien später direkt im Editor öffnen möchte.

code/framework-labs/
├── order-platform-core              # fachlicher Kern, JDK-only, geprüft
├── spring-boot-order-api            # Spring Boot HTTP Adapter
├── jakarta-ee-order-api             # Jakarta EE WAR/JAX-RS Adapter
├── quarkus-order-api                # Quarkus REST/CDI Adapter
└── micronaut-order-api              # Micronaut HTTP/DI Adapter

Reihenfolge beim Lesen

1. order-platform-core/docs/design-patterns.html
2. order-platform-core/src/main/java/.../domain/Order.java
3. order-platform-core/src/main/java/.../application/PlaceOrderUseCase.java
4. order-platform-core/src/main/java/.../application/OrderFulfillmentSaga.java
5. danach je Framework den Controller oder die Resource öffnen

Was bewusst gleich ist

Was bewusst unterschiedlich ist

Mini-UML

+--------------------+       +---------------------+
| OrderController    | ----> | PlaceOrderUseCase   |
| OrderResource      |       +---------------------+
+--------------------+                 |
          |                             v
          |                  +---------------------+
          |                  | OrderRepository     |
          |                  | OutboxPort          |
          |                  +---------------------+
          v                             |
+--------------------+                 v
| HTTP Runtime       |       +---------------------+
| Spring/Jakarta/... |       | Adapter Impl        |
+--------------------+       +---------------------+

Architekturregel

Der Core importiert keine Frameworkpakete. Das ist der wichtigste Check der Version 3.

Erlaubt im Core:
java.*, java.time.*, java.math.*, eigene Domain- und Application-Pakete

Nicht erlaubt im Core:
org.springframework.*, jakarta.ws.rs.*, io.quarkus.*, io.micronaut.*

Framework Entscheidungsmatrix

Zweck

Diese Matrix ist keine absolute Bewertung. Sie hilft, im Enterprise-Kontext sauberer zu argumentieren.

Empfehlung nach Situation

Warnsignale

• Framework wird gewählt, bevor fachliche Grenzen klar sind.
• Controller enthalten Preislogik, Statuslogik oder Transaktionsentscheidungen.
• Domain-Klassen importieren HTTP-, DI- oder Persistence-Frameworks ohne bewusste Entscheidung.
• Tests starten immer den ganzen Container, obwohl Core-Tests reichen würden.
• Migration wird als Dependency-Update statt als Architekturarbeit verstanden.

Runtime und Abhängigkeiten modernisieren

Dieser Teil ergänzt das Enterprise-Java-Lese- und Referenzbuch um eine aktuelle Runtime-Modernisierungsschicht. Der wichtigste Punkt: Das Buch bleibt fachlich bei Java 11, Java 17 und Java 21, aber die Framework-Welt bewegt sich weiter. Deshalb werden neue Baselines sauber getrennt dokumentiert.

Ziel der Erweiterung

Nach Grundlagen, Architektur und Framework-Vergleich beantwortet dieser Teil die Frage:

Wie modernisiere ich ein Enterprise-Java-System 2026, ohne meine Java-21-Lernlinie, meine Architekturgrenzen und meine Betriebsfähigkeit zu zerstören?

Dazu wurden ergänzt:

• neue Runtime-Matrix für Spring Boot 4.x, Jakarta EE 11, Quarkus 3.33 LTS, Micronaut 4/5
• Dependency-Governance mit BOMs, Maven Enforcer, SBOM und CVE-Checks
• Entscheidungsbaum für Upgrade-Pfade
• Java-21-Core-Stabilitätsregel
• separates Runtime-Modernization-Lab mit Java-Code
• Maven-POM-Beispiele für Profile und Versionstrennung
• neue SVG/PNG-Diagramme
• aktualisierte Checks, Indexe und Was-wurde-gemacht-Dateien

Quellenstand und Einordnung

Stand: 08.07.2026. Für die Runtime-Entscheidungen wurden bewusst offizielle Projektquellen verwendet:

• Spring Boot System Requirements: Spring Boot 4.1.0 verlangt Java 17 oder höher und Spring Framework 7.0.8 oder höher.
• Spring Boot 4 Migration Guide: Spring Boot 4 basiert auf Jakarta EE 11, Servlet 6.1 und entfernt nicht mehr passende Altpfade wie Undertow-Support in diesem Release.
• Jakarta EE 11 Release-Seite und Release Plan: Jakarta EE 11 modernisiert die Plattform, enthält Jakarta Data und richtet sich auf Java 17/21 aus; die Platform-API nutzt --release 17.
• Quarkus Releases und Quarkus 3.33 Blog: Quarkus 3.33 ist die aktuelle LTS-Spur; LTS-Releases erhalten kritische Fixes und Security-Patches für 12 Monate.
• Micronaut 5.0 Release und Baseline-Hinweis: Micronaut 5 setzt Java 25 als Baseline. Deshalb wird Micronaut 5 im Java-11/17/21-Buch als Zukunftsspur und nicht als Haupt-Lab geführt.

Die zentrale Entscheidung

Warum diese Trennung wichtig ist

Ein Enterprise-Projekt scheitert selten daran, dass eine neue Version nicht kompiliert. Es scheitert eher daran, dass unklare Baselines, vermischte Framework-Abhängigkeiten, unvollständige Tests und fehlende Betriebsnachweise den Release unkontrollierbar machen.

Deshalb gilt für die Modernisierung:

Fachlicher Core      -> Java 21, stabil, ohne Framework-Imports
Framework-Adapter    -> dürfen je Runtime modernisiert werden
Build Governance     -> Maven Enforcer, BOMs, Dependency Locks, SBOM
Betriebsnachweis     -> Health, Metrics, Logs, Images, Rollback
Zukunftsbaselines    -> separat dokumentieren, nicht heimlich mischen

Architekturregel: Core bleibt ruhig, Adapter bewegen sich

Der Core enthält Domänenmodell, Use Cases, Ports, fachliche Fehler und Tests. Der Core sollte nicht wissen, ob die Anwendung später als Spring Boot JAR, Jakarta WAR, Quarkus Container oder Micronaut Service läuft.

// Pattern: Hexagonal Architecture / Ports and Adapters
public final class UpgradePlanner {
    private final RuntimePolicyRepository policies;
    private final RiskClassifier riskClassifier;

    public UpgradePlan planFor(ApplicationInventory inventory) {
        RuntimePolicy policy = policies.findBestPolicyFor(inventory.targetRuntime());
        return UpgradePlan.builder(inventory.name())
                .baseline(policy.recommendedJavaBaseline())
                .risk(riskClassifier.classify(inventory, policy))
                .addStep("Core gegen Java 21 prüfen")
                .addStep("Adapter-Dependencies getrennt aktualisieren")
                .addStep("SBOM und Lizenzbericht erzeugen")
                .addStep("Rollback und Betriebsmetriken dokumentieren")
                .build();
    }
}

Upgrade-Entscheidungsbaum

Entscheidung 1: Bestehender Application Server

Wenn eine Organisation viele WAR-Deployments, zentrale Transaktionen, Application-Server-Betrieb und Jakarta-Standards nutzt, ist Jakarta EE 11 der natürlichere Modernisierungspfad. Der Fokus liegt dann auf API-Update, Server-Kompatibilität, Packaging und Integrationstests.

Entscheidung 2: Spring-Ökosystem

Wenn Actuator, Spring Security, Spring Data, Spring Batch, Spring Cloud oder bestehende Spring-Kompetenz wichtig sind, ist Spring Boot 4.x die passende Modernisierungsspur. Man muss aber Dependency-Management, entfernte Deprecations und Servlet-6.1-Baseline bewusst prüfen.

Entscheidung 3: Container First

Wenn Startzeit, Memory-Footprint, Kubernetes-Nähe und native Build-Optionen im Vordergrund stehen, ist Quarkus 3.33 LTS eine gute Spur. In Version 4 wird Quarkus als Java-21-kompatibler Produktionspfad dokumentiert.

Entscheidung 4: Micronaut 5 und Java 25

Micronaut 5 ist fachlich interessant, aber für dieses Buch eine getrennte Zukunftsspur, weil die Hauptlinie Java 11/17/21 ist.

Spring Boot 4.x und Jakarta EE 11 Stack

Spring Boot 4.x ist nicht nur ein Versionssprung von Boot 3.x. Es ist auch ein Schritt auf eine neue Spring-Framework-Generation, eine Jakarta-EE-11-Grundlage und eine neue Servlet-Baseline. Daraus folgen typische Aufgaben:

• veraltete APIs aus Boot 3.x vor dem Sprung entfernen
• Starter-Abhängigkeiten prüfen
• Security-Konfigurationen testen
• Servlet-Container-Kompatibilität klären
• Observability und Actuator-Endpunkte prüfen
• Integrationstests gegen echte HTTP-Flows ausführen

Jakarta EE 11 im Buchkontext

Jakarta EE 11 ist wichtig, weil viele Enterprise-Landschaften nicht nur aus Microservices bestehen. Es gibt weiterhin Application Server, WARs, zentrale Betriebsmodelle, JTA, JPA, JMS, Security-Domänen und klassische Mandantenlogik.

Für das Buch bedeutet das:

Jakarta EE 11 ist nicht altmodisch.
Es ist die Standardplattform für containerverwaltete Enterprise-Java-Systeme.

Quarkus 3.33 LTS im Buchkontext

Quarkus 3.33 LTS wird als stabile Produktionsspur für containernahe Java-Services ergänzt. Die Lernregel bleibt:

Quarkus-spezifisch: Resource, CDI-Wiring, Config, Extension-Auswahl
Core-spezifisch: Domain, Use Case, Ports, fachliche Tests

Dependency-Governance statt Versionsraten

Eine moderne Enterprise-Java-Plattform braucht eine zentrale Steuerung:

<properties>
  <java.release>21</java.release>
  <spring.boot.version>4.1.0</spring.boot.version>
  <jakarta.ee.version>11.0.0</jakarta.ee.version>
  <quarkus.platform.version>3.33.1.1</quarkus.platform.version>
  <micronaut.java21.track>4.x</micronaut.java21.track>
  <micronaut.java25.track>5.0.0</micronaut.java25.track>
</properties>

Wichtig: Diese Werte sind Lern- und Architekturanker. In einem echten Projekt müssen sie über Repository-Policy, Vendor-Support, CVE-Status, Build-Reproduzierbarkeit und Testabdeckung freigegeben werden.

Release-Train-Matrix

Neues Runtime-Modernization-Lab

Version 4 ergänzt ein eigenes Lab:

code/runtime-modernization-lab/
├── pom.xml
├── README.md / README.html
├── docs/design-patterns.md / design-patterns.html
└── src/main/java/com/example/enterprisejava/runtime2026/

Das Lab ist bewusst JDK-only kompilierbar, damit es in dieser Umgebung ohne Maven-Download geprüft werden kann. Die POM-Datei enthält trotzdem die Enterprise-Modernisierungslogik mit zentralen Properties, Enforcer-Kommentaren und Profilen.

Lernziel dieses Teils

Danach soll man nicht nur wissen, welche Framework-Version modern ist. Man soll erklären können:

• warum Java 21 als fachlicher Core stabil bleiben kann
• warum Spring Boot 4.x und Jakarta EE 11 zusammen betrachtet werden müssen
• warum Quarkus LTS für Produktion anders zu behandeln ist als normale Minor Releases
• warum Micronaut 5 wegen Java 25 getrennt betrachtet wird
• wie Dependency-Governance ein Upgrade kontrollierbar macht
• welche Design Patterns helfen, Framework-Wechsel ohne Fachlogik-Umbau zu ermöglichen

Runtime-Modernisierung 2026: stabile Java-21-Lernlinie mit aktuellen Frameworks

Dieses Kapitel ist die operative Anleitung zu Version 4. Es beantwortet: Wie gehe ich in einem echten Enterprise-Projekt vor, wenn die Framework-Welt aktueller ist als die Java-LTS-Zielarchitektur des Unternehmens?

Quellenstand und Einordnung

Stand: 08.07.2026. Für die Runtime-Entscheidungen wurden bewusst offizielle Projektquellen verwendet:

• Spring Boot System Requirements: Spring Boot 4.1.0 verlangt Java 17 oder höher und Spring Framework 7.0.8 oder höher.
• Spring Boot 4 Migration Guide: Spring Boot 4 basiert auf Jakarta EE 11, Servlet 6.1 und entfernt nicht mehr passende Altpfade wie Undertow-Support in diesem Release.
• Jakarta EE 11 Release-Seite und Release Plan: Jakarta EE 11 modernisiert die Plattform, enthält Jakarta Data und richtet sich auf Java 17/21 aus; die Platform-API nutzt --release 17.
• Quarkus Releases und Quarkus 3.33 Blog: Quarkus 3.33 ist die aktuelle LTS-Spur; LTS-Releases erhalten kritische Fixes und Security-Patches für 12 Monate.
• Micronaut 5.0 Release und Baseline-Hinweis: Micronaut 5 setzt Java 25 als Baseline. Deshalb wird Micronaut 5 im Java-11/17/21-Buch als Zukunftsspur und nicht als Haupt-Lab geführt.

Modernisierung ist mehrdimensional

Viele Teams behandeln Modernisierung wie eine Liste neuer Versionen. Das ist gefährlich. In Enterprise-Systemen müssen mindestens sechs Dimensionen gleichzeitig betrachtet werden:

Die wichtigste Buchregel

Der Java-21-Core ist kein Spielball der Framework-Versionen.
Framework-Adapter dürfen sich ändern, aber die Fachlogik bleibt stabil.

Modernisierungssequenz

1. Anwendung inventarisieren: Java-Version, Framework, Packaging, Datenbank, Messaging, Security.
2. Fachlichen Core identifizieren und Framework-Imports entfernen.
3. Java-21-Kompilierung mit --release 21 erzwingen.
4. Runtime-Ziel wählen: Spring Boot 4.x, Jakarta EE 11, Quarkus 3.33 LTS, Micronaut 4.x oder Java-25-Spur.
5. BOMs zentralisieren.
6. Maven Enforcer Regeln aktivieren.
7. SBOM und Lizenzbericht erzeugen.
8. Integrationstests gegen echte Adapter laufen lassen.
9. Betriebsnachweise prüfen: Health, Metrics, Logs, Rollback.
10. Ergebnis im Architekturentscheid dokumentieren.

Beispiel: ADR für Runtime-Entscheidung

# ADR: Runtime-Modernisierung Order API 2026

## Entscheidung
Wir halten den fachlichen Core auf Java 21 stabil und modernisieren den HTTP-Adapter auf Spring Boot 4.x.

## Begründung
Das Team nutzt Spring Security, Actuator und Spring Data intensiv. Der Core enthält keine Spring-Imports.

## Konsequenzen
- Spring Framework 7.x und Jakarta EE 11 Baseline prüfen
- Servlet-6.1-Kompatibilität sicherstellen
- Integrationstests und Security-Tests aktualisieren
- SBOM und Rollback-Dokument erzeugen

Typische Fehler

Spring Boot 4.x und Jakarta EE 11: Modernisierung ohne Architekturbruch

Spring Boot 4.x und Jakarta EE 11 gehören in der Modernisierung zusammen betrachtet, weil Spring Boot 4 auf einer neuen Jakarta-EE-Grundlage und Servlet-6.1-Baseline sitzt. Das bedeutet: Auch wenn die Anwendung wie eine normale Spring-Boot-Anwendung aussieht, ändern sich darunter API- und Containerannahmen.

Was sich fachlich nicht ändern sollte

Die folgenden Klassen sollten nicht wissen, ob Spring Boot 4 oder Jakarta EE 11 verwendet wird:

Order
OrderLine
Money
PlaceOrderUseCase
PaymentPort
OutboxPort
OrderRepository

Diese Klassen gehören in den Core.

Was sich ändern darf

Spring @RestController
Spring @Configuration
Spring Security Konfiguration
Jakarta @Path Resource
CDI Producer
Exception Mapper
Servlet Packaging
Actuator / Health Endpoints

Diese Klassen gehören in Adapter.

Upgrade-Checkliste Spring Boot 4.x

Beispiel: Core bleibt frei

// Kein Spring, kein Jakarta, kein Quarkus, kein Micronaut im Core.
public interface PaymentPort {
    PaymentDecision authorize(PaymentRequest request);
}

Beispiel: Spring Adapter

// Pattern: Adapter - HTTP und Framework-Anmerkungen bleiben außen.
@RestController
@RequestMapping("/orders")
final class OrderController {
    private final PlaceOrderUseCase useCase;

    OrderController(PlaceOrderUseCase useCase) {
        this.useCase = useCase;
    }
}

Beispiel: Jakarta Adapter

// Pattern: Adapter - JAX-RS Resource übersetzt HTTP in Use Case.
@Path("/orders")
public class OrderResource {
    @Inject PlaceOrderUseCase useCase;
}

Entscheidungsregel

Wenn das Unternehmen bereits Spring-Kompetenz und Spring-Ökosystem verwendet, ist Spring Boot 4.x naheliegend. Wenn es stark auf standardisierte Application Server, WARs und containerverwaltete Enterprise Services setzt, ist Jakarta EE 11 naheliegender.

Quarkus 3.33 LTS und Micronaut-Entscheidung 2026

Quarkus und Micronaut sind beide moderne Enterprise-Java-Frameworks, aber in Version 4 werden sie unterschiedlich behandelt.

Quarkus 3.33 LTS

Quarkus 3.33 LTS wird im Buch als produktionsnahe Container- und Cloud-Native-Spur geführt. Die LTS-Eigenschaft ist wichtig, weil Enterprise-Projekte nicht jede Minor-Version sofort übernehmen können.

Gute Einsatzfälle

Micronaut 4.x für Java-21-Labs

Micronaut bleibt im Java-21-Lernbuch sinnvoll, solange die verwendete Spur Java 21 unterstützt. In Version 4 wird Micronaut deshalb als Java-21-kompatibler Track und zusätzlich als Java-25-Zukunftspfad dokumentiert.

Micronaut 5.x als Java-25-Zukunftspfad

Micronaut 5 setzt Java 25 als Baseline. Das ist kein Nachteil, aber es passt nicht direkt in ein Buch, dessen Hauptziel Java 11, 17 und 21 ist. Deshalb gilt:

Micronaut 4.x -> Java-21-Lab
Micronaut 5.x -> Java-25-Zukunftskapitel

Entscheidungsmatrix

Musterentscheidung

Für ein Java-21-Enterprise-Lernprojekt nehmen wir Quarkus 3.33 LTS und Micronaut 4.x.
Micronaut 5 wird als Java-25-Track vorbereitet, aber nicht in den Java-21-Core integriert.

Dependency-Upgrade-Matrix 2026

Diese Referenz ist die kompakte Matrix für Version 4. Sie dient als Entscheidungs- und Prüfblatt für Enterprise-Java-Upgrades.

Hauptmatrix

Build-Regeln

Beispiel-POM-Ausschnitt

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>${spring.boot.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Freigaberegel

Eine Dependency wird nicht freigegeben, weil sie neu ist. Sie wird freigegeben, wenn folgende Nachweise vorhanden sind:

Build OK
Tests OK
SBOM vorhanden
CVE-Risiko bewertet
Lizenzstatus bewertet
Betriebsprobe bestanden
Rollback dokumentiert

Java Runtime Support Matrix 2026

Diese Matrix trennt Lernlinie, Produktionslinie und Zukunftslinie.

Java 11

Java 11 ist im Buch wichtig, weil viele reale Enterprise-Systeme von Java 8 auf Java 11 modernisiert wurden oder noch auf Java 11 stehen. Für neue Architekturentscheidungen ist Java 11 aber meist nicht mehr die Zielbasis.

Java 17

Java 17 ist eine wichtige Mindestbasis, weil viele moderne Frameworks mindestens Java 17 verlangen. Wer von Java 8/11 kommt, kann Java 17 als technische Brücke nutzen.

Java 21

Java 21 ist die Hauptlinie des Pakets. Sie ist stark genug für moderne Sprache, Virtual Threads und stabile Enterprise-Architekturen.

Java 25

Java 25 wird nicht ignoriert, aber getrennt behandelt. Sobald ein Framework Java 25 als Baseline setzt, entsteht eine eigene Modernisierungsspur mit Build-, Runtime- und Betriebsfolgen.

Große Annotationen-Sammlung Enterprise Java

Diese Sammlung erklärt häufige Annotationen aus Java, Jakarta, JPA, Bean Validation, Spring und Testing. Sie ist als Nachschlagewerk gedacht.

Java und JVM-nahe Annotationen

Jakarta / CDI

JPA

Bean Validation

Spring

Testing

Maven Plugin Sammlung für Enterprise Java

Diese Sammlung nennt wichtige Maven Plugins mit typischem Zweck und Beispielkonfiguration.

Compiler Plugin

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.13.0</version>
  <configuration>
    <release>21</release>
  </configuration>
</plugin>

Enforcer Plugin

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.5.0</version>
  <executions>
    <execution>
      <goals><goal>enforce</goal></goals>
      <configuration>
        <rules>
          <requireJavaVersion><version>[21,)</version></requireJavaVersion>
          <requireMavenVersion><version>[3.9,)</version></requireMavenVersion>
        </rules>
      </configuration>
    </execution>
  </executions>
</plugin>

Surefire und Failsafe

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>3.3.1</version>
</plugin>
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-failsafe-plugin</artifactId>
  <version>3.3.1</version>
</plugin>

JaCoCo

<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <version>0.8.12</version>
  <executions>
    <execution><goals><goal>prepare-agent</goal></goals></execution>
    <execution><id>report</id><phase>verify</phase><goals><goal>report</goal></goals></execution>
  </executions>
</plugin>

Versions Plugin

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>versions-maven-plugin</artifactId>
  <version>2.17.1</version>
</plugin>

Regel

Plugin-Versionen sollten niemals implizit bleiben. Ein reproduzierbarer Enterprise-Build kontrolliert jedes Plugin bewusst.

Glossar Enterprise Java