Java-Modulsystem unterbricht die Serialisierung von Standardbibliotheksklassen – Gibt es eine bessere Lösung als --add-o ⇐ Java

[Anonymous]

Problem
Beim Serialisieren von Java-Standardbibliotheksklassen (wie java.awt.Rectangle, Point, Dimension usw.) mit Frameworks wie

Code: Select all

--add-opens java.desktop/java.awt=ALL-UNNAMED

Dies ist erforderlich, da Serialisierungsframeworks Deep-Reflection-Zugriff auf private Felder benötigen, das Modulsystem dies jedoch blockiert, obwohl mein Code Modulabhängigkeiten ordnungsgemäß deklariert:

Code: Select all

module my.app {
requires java.desktop;  // Not sufficient for reflection!
}

Das Kernproblem
Ich kann die Pakete eines anderen Moduls nicht aus meiner module-info.java öffnen – das kann nur das besitzende Modul. Die open-Direktive funktioniert nur für Ihre eigenen Pakete:

Code: Select all

module my.app {
opens my.package to com.thoughtworks.xstream;  // ✓ Works for MY packages
requires java.desktop;                          // ✗ Doesn't open THEIR packages
}

Dieses Design scheint für legitime Serialisierungsanwendungsfälle grundlegend fehlerhaft zu sein.
Warum das wichtig ist

• Code: Select all

  --add-opens

  ist ein Wartungsalbtraum[/b] – Alle betroffenen Module müssen über alle JDK-Versionen hinweg verfolgt werden
• Nur-Laufzeit-Lösung – Kann nicht im Code deklariert werden, schwer zu erkennen, wenn sie fehlen
• Standardbibliotheksklassen sind nicht exotisch – Dies sind normale, stabile öffentliche APIs (

  Code: Select all

  Rectangle

  , Farbe, Datei usw.)
• Betrifft alle reflexionsbasierten Frameworks – Nicht nur Serialisierung, sondern auch ORMs, Test-Frameworks usw.

Fragen

• Gibt es eine umfassende Bibliothek, die Serialisierungskonverter/-adapter für gängige JDK bereitstellt? Klassen? Ich suche speziell nach XStream-Konvertern, bin aber auch an Lösungen für Jackson/Gson interessiert.
• Warum stellt das JDK kein „serialisierungsfreundliches“ Modul bereit, das diese stabilen Klassen explizit zur Reflexion öffnet? Etwas wie java.desktop.reflection, das optional erforderlich sein könnte?
• Gibt es Vorschläge oder JEPs, die diese Reibung zwischen Modulen und Reflexion beheben?

Was könnte eine Lösung sein?

• DTOs/Wrapper-Klassen – Zu viel Boilerplate für Dutzende von JDK-Klassen
• Benutzerdefinierte Konverter – Funktioniert, erfordert aber das Schreiben von Konvertern für jede JDK-Klasse, die ich serialisiere

Kontext

• Verwendung von XStream für die Konfigurationsserialisierung
• Es müssen komplexe Objektdiagramme mit AWT-Geometrieklassen serialisiert werden
• Java 17+, modulare Anwendung