Spezifikation / Library-APIJSON3.0

Jakarta JSON Binding

JSON-B bindet POJOs an JSON und zurück, ähnlich wie Jackson, aber als Jakarta-Standard.

Einordnung
Spezifikation / Library-API
Enterprise-Rolle
Es reduziert Mapping-Code und bleibt portabler innerhalb Jakarta-Runtimes.
Diagramm zu Jakarta JSON Binding

Fachliches Verständnis

Es reduziert Mapping-Code und bleibt portabler innerhalb Jakarta-Runtimes. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.

Kernkonzepte

  • Automatisches Binding.
  • Anpassung mit Annotationen.
  • Adapter und Serialisierungsregeln.

Typische Einsatzfälle

  • REST DTOs serialisieren.
  • Events als JSON darstellen.
  • Konfigurierbare Datums-/Namenformate.

Technisches Beispiel

java
public record CustomerDto(String number, String name, LocalDate registeredAt) {}

Jsonb jsonb = JsonbBuilder.create(new JsonbConfig()
    .withDateFormat("yyyy-MM-dd", Locale.GERMANY));

String json = jsonb.toJson(new CustomerDto("C-42", "Aydin", LocalDate.now()));
CustomerDto dto = jsonb.fromJson(json, CustomerDto.class);
Architekturregel: Jakarta APIs gehören an Systemgrenzen und Infrastrukturpunkte. Fachentscheidungen bleiben in Application Services und Domain-Modellen testbar und möglichst unabhängig vom Container.

Enterprise-Fallen

  • Domain Entities direkt serialisieren.
  • Zyklische Objektgraphen.
  • Provider-spezifische Features als Standard annehmen.

Legacy-Modernisierung

Alte DTO-Mapper lassen sich teilweise durch JSON-B ersetzen, solange API-Verträge sauber bleiben.

Vertiefung: Review-Fragen für Senior-Entwickler
  • Welche Spezifikation ist hier wirklich nötig?
  • Welche Runtime-Funktion wird genutzt und ist sie portabel?
  • Wo liegt die Transaktionsgrenze?
  • Sind API-Verträge, DTOs und Domain-Modelle getrennt?
  • Ist der Code ohne Application Server testbar?
Jakarta JSON ProcessingIndex