Система модулей Java, нарушающая сериализацию классов стандартной библиотеки. Есть ли лучшее решение, чем --add-opens? ⇐ JAVA

[Anonymous]

Проблема
При сериализации классов стандартной библиотеки Java (таких как java.awt.Rectangle, Point, Dimension и т. д.) с использованием таких платформ, как XStream, Jackson или Gson, я вынужден использовать флаги --add-opens:

Код: Выделить всё

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

Это необходимо, поскольку платформам сериализации требуется доступ к закрытым полям с глубоким отражением, но система модулей блокирует это, хотя мой код правильно объявляет зависимости модулей:

Код: Выделить всё

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

Основная проблема
Я не могу открыть пакеты другого модуля из моего модуля-info.java — это может сделать только модуль-владелец. Директива opens работает только для ваших собственных пакетов:

Код: Выделить всё

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

Похоже, что эта конструкция в корне не подходит для законных случаев использования сериализации.
Почему это важно

• Код: Выделить всё

  --add-opens

   — кошмар для обслуживания.[/b] – Необходимо отслеживать все затронутые модули во всех версиях JDK.
• Решение, предназначенное только для выполнения.    Не может быть объявлено в коде, его трудно обнаружить при отсутствии.
• Классы стандартной библиотеки не являются экзотикой. – Это обычные, стабильные общедоступные API (

  Код: Выделить всё

  Rectangle

  , Color, File и т. д.)
• Влияет на все платформы на основе отражения – не только сериализация, но также ORM, платформы тестирования и т. д.

Вопросы

• Существует ли комплексная библиотека, предоставляющая преобразователи/адаптеры сериализации для обычного JDK классы? Специально ищете преобразователи XStream, но также заинтересованы в решениях для Jackson/Gson.
• Почему JDK не предоставляет «дружественный к сериализации» модуль, который явно открывает эти стабильные классы для отражения? Что-то вроде java.desktop.reflection, которое может потребоваться дополнительно?
• Есть ли какие-либо предложения или JEP, устраняющие это противоречие между модулями и отражением?

Какое может быть решение?

• DTO/классы-оболочки - тоже много шаблонов для десятков классов JDK
• Пользовательские преобразователи – работает, но требует написания преобразователей для каждого сериализуемого класса JDK

Контекст

• Использование XStream для сериализации конфигурации
• Необходимость сериализации сложных графов объектов, содержащих классы геометрии AWT
• Java 17+, модульное приложение

Подробнее здесь: https://stackoverflow.com/questions/798 ... s-is-there