Выборочное использование сторонней реализации для устаревших модулей JavaEE - PullRequest
Новая
       35

Выборочное использование сторонней реализации для устаревших модулей JavaEE

0 голосов
/ 02 января 2019

В настоящее время я портирую библиотеку с открытым исходным кодом для совместимости с JDK9 +, и это зависит от некоторых модулей Java EE, которые устарели в Java 9 и удалены в Java 11: в частности, JAXB, JAX-WS и javax.annotation .

Я добавил явные зависимости к сторонним реализациям, как предлагалось здесь : 

<dependency>
  <groupId>com.sun.xml.ws</groupId>
  <artifactId>jaxws-ri</artifactId>
  <version>2.3.0.1</version>
</dependency>
<dependency>
  <groupId>com.sun.xml.bind</groupId>
  <artifactId>jaxb-ri</artifactId>
  <version>2.3.0.1</version>
</dependency>
<dependency>
  <groupId>com.sun.activation</groupId>
  <artifactId>javax.activation</artifactId>
  <version>1.2.0</version>
</dependency>

Однако я бы хотел, чтобы моя библиотека использовала их только в случае необходимости (т.е. в JDK9 +) и продолжала использовать одобренные реализации в JDK8.

Я могу сделать это, добавив зависимости в профиле Maven, которые будут активированы только в JDK 9 и выше, но что если я захочу опубликовать файл jar для своей библиотеки в Maven Central? Должен ли я публиковать два разных jar-файла, один с включенными сторонними реализациями Java EE, для JDK9 + и один без для JDK8?

Есть ли способ создать файл JAR, который будет использовать сторонние реализации на JDK9 + и одобренные на JDK8?

Я рассмотрел мульти-релиз jar , но похоже, что они предназначены для реализаций, зависящих от версии jdk, между классами проекта, а не между зависимостями.

Кроме того, если невозможно использовать одобренные реализации в JDK 8, есть ли способ надежно проверить, что использование сторонних реализаций не приводит к регрессиям?

1 Ответ

0 голосов
/ 13 января 2019

Есть ли способ создать jar-файл, который будет использовать третья сторона реализации на JDK9 + и одобренные на JDK8?

К сожалению, нет. Распространяя библиотеку через файл jar, вы не можете контролировать, как другие jar и библиотеки будут перечислены в classpath. Это делает загрузку классов недетерминированной для вас. Для вашей ситуации это означает, что если вышеупомянутые библиотеки включены в путь к классам в среде JDK8, то невозможно определить или контролировать, какая версия классов загружается.

Кроме того, в случае, если невозможно использовать одобренные реализации на JDK 8, есть ли способ надежно проверить, что с помощью третьей стороны реализации не вводит никаких регрессий?

Как автор, вы должны выполнить тесты в различных средах выполнения для проверки регрессий.

Должен ли я публиковать две разные банки, одна с третьей стороной Java EE Реализации включены, для JDK9 + и один без для JDK8?

Это вполне разумное решение, которое раньше использовали и другие. Возьмите, например, jl sqbserver jdbc, которые имеют разные версии на основе jre: https://docs.microsoft.com/en-us/sql/connect/jdbc/using-the-jdbc-driver?view=sql-server-2017 Для описанного здесь случая jar-версия JDK9 + может объявить дополнительные зависимости, которые вы упомянули в вопросе, а версия JDK8 - нет.

Еще один вариант - иметь один jar и объявить зависимости, которые вы упомянули, как указано. Это будет сигнализировать потребителю, что среда выполнения должна включать классы в объявленные зависимости. Потребуется некоторая документация, чтобы указать потребителю библиотеки, когда нужно явно добавить jar-файлы, объявленные как предоставленные для их пути к классам.

ИМХО, самое ясное решение - это две банки со ссылкой на версию JRE в имени банки и различные зависимости. Это требует очень мало документации (которую большинство не смотрит в любом случае). И это позволяет вам делать изменения в вашей библиотеке более свободно.

...