Замена устаревших модулей JPMS на API Java EE

183

Java 9 устарела из шести модулей, которые содержат API Java EE, и они скоро будут удалены :

  • java.активация с javax.activationпакетом
  • java.corba с javax.activity, javax.rmi, javax.rmi.CORBAи org.omg.*пакеты
  • сделка с javax.transactionпакетом
  • java.xml.bind со всеми javax.xml.bind.*пакетами
  • java.xml.ws с javax.jws, javax.jws.soap, javax.xml.soapи все javax.xml.ws.*пакеты
  • java.xml.ws.annotation с javax.annotationпакетом

Какие поддерживаемые сторонние артефакты предоставляют эти API? Неважно, насколько хорошо они предоставляют эти API или какие другие функции они могут предложить - все, что имеет значение, являются ли они заменой этих модулей / пакетов?

Чтобы было проще собирать знания, я ответил тем, что знаю до сих пор, и сделал ответ вики-сообществом. Я надеюсь, что люди расширят его вместо того, чтобы писать свои собственные ответы.


Прежде чем голосовать, чтобы закрыть:

  • Да, уже есть несколько вопросов по отдельным модулям, и ответ на этот вопрос, конечно, дублирует эту информацию. Но AFAIK нет единого смысла, чтобы узнать обо всем этом, что я думаю, имеет большую ценность.
  • Вопросы с просьбой дать рекомендации по библиотекам обычно считаются не по теме, потому что «они, как правило, привлекают взвешенные ответы и спам», но я не думаю, что это применимо здесь. Набор допустимых библиотек четко разграничен: они должны реализовывать определенный стандарт. Кроме этого, ничего больше не имеет значения, поэтому я не вижу большого риска для мнения и спама.
Nicolai
источник
6
В основном вы можете найти всех тех, кто был перемещен в github.com/javaee и ссылки на некоторые подробности в JEP 320: Удалить модули Java EE и CORBA
Naman
См. Также эту статью 2018-05-14 в InfoWorld, дорожная карта Java: Eclipse Jakarta EE Enterprise Java принимает форму Пола Криля. Подзаголовок: Фонд Eclipse описывает 39 проектов, которые составят новую облачную, ориентированную на микросервисы корпоративную Java-работу и то, как GlassFish будет развиваться
Бэзил Бурк
2
Из JDK 11 он был удален. Если вы используете jdk 9 или выше, лучше добавить зависимость напрямую, а не с помощью вида «--add-modules java.xml.bind»
Anver Sadhat,

Ответы:

205

Вместо использования устаревших модулей Java EE используйте следующие артефакты.

JAF ( java.activation )

JavaBeans Activation Framework (в настоящее время Jakarta Activation ) - это отдельная технология (доступная в Maven Central):

<dependency>
    <groupId>com.sun.activation</groupId>
    <artifactId>jakarta.activation</artifactId>
    <version>1.2.2</version>
</dependency>

( Источник )

CORBA ( java.corba )

От JEP 320 :

Автономной версии CORBA не будет, если третьи стороны не возьмут на себя поддержку API-интерфейсов CORBA, реализацию ORB, поставщика CosNaming и т. Д. Возможно стороннее обслуживание, поскольку платформа Java SE поддерживает независимые реализации CORBA. Напротив, API для RMI-IIOP определяется и реализуется исключительно в Java SE. Не будет отдельной версии RMI-IIOP, пока не будет запущена выделенная JSR для ее обслуживания или если управление Eclipse Foundation перешло к управлению API (переход координирующей роли Java EE от JCP к Eclipse Foundation включает GlassFish и его реализация CORBA и RMI-IIOP).

JTA ( java.transaction )

Автономная версия:

<dependency>
    <groupId>jakarta.transaction</groupId>
    <artifactId>jakarta.transaction-api</artifactId>
    <version>1.3.3</version>
</dependency>

( Источник )

JAXB ( java.xml.bind )

Поскольку Java EE был переименован в Jakarta EE , JAXB теперь представлен новыми артефактами:

<!-- API -->
<dependency>
    <groupId>jakarta.xml.bind</groupId>
    <artifactId>jakarta.xml.bind-api</artifactId>
    <version>2.3.3</version>
</dependency>

<!-- Runtime -->
<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-impl</artifactId>
    <version>2.3.3</version>
    <scope>runtime</scope>
</dependency>

Справочная страница JAXB .

schemagen и xjc может быть загружен там также как часть автономного дистрибутива JAXB.

Смотрите также связанный ответ .

JAX-WS ( java.xml.ws )

Эталонная реализация:

<!-- API -->
<dependency>
    <groupId>jakarta.xml.ws</groupId>
    <artifactId>jakarta.xml.ws-api</artifactId>
    <version>2.3.3</version>
</dependency>

<!-- Runtime -->
<dependency>
    <groupId>com.sun.xml.ws</groupId>
    <artifactId>jaxws-rt</artifactId>
    <version>2.3.3</version>
</dependency>

Загрузка отдельного дистрибутива (содержит wsgenиwsimport ).

Общие аннотации ( java.xml.ws.annotation )

Аннотации Java Commons (доступны на Maven Central):

<dependency>
    <groupId>jakarta.annotation</groupId>
    <artifactId>jakarta.annotation-api</artifactId>
    <version>1.3.5</version>
</dependency>

( Источник )

Николай
источник
Что делать в случае, если модуль читает jax-wsиз jdk и com.sun.xml.wsзависимости?
nllsdfx
1
Я не уверен, что именно ты спрашиваешь. Какой модуль читает jax-ws? Если у вас есть файл java.xml.ws в графе модулей и com.sun.xml.ws:jaxws-ri в пути к классам, последний будет проигнорирован (из-за разделения пакетов ).
Николай
Ну, я хочу использовать com.sun.xml.ws:jaxws-riвместо java.xml.wsмоего модуля, потому что последний устарел и будет удален. И я добавил зависимость в мой pom-файл, и появилась ошибка «модуль xyz читает пакет« javax.xml.ws »как из java.xml.ws, так и из java.xml.ws».
nllsdfx
Похоже, что модуль java.xml.ws разрешен в конце концов, возможно, из-за --add-modulesили потому, что это требуется некоторым другим модулям. Можете ли вы открыть новый вопрос, чтобы мы могли посмотреть на него?
Николай
1
Это правда. Две детали: (1) Если никакой явный модуль (то есть модуль с объявлением модуля) не зависит от JAXB, вы все равно можете разместить их в пути к классам, где разделенные пакеты не имеют значения. (2) Опция командной строки --patch-moduleможет исправить разделение.
Николай
25

JAXB (java.xml.bind) для JDK9

Отлично работает в моих настольных приложениях на jdk9 / 10 EA

<properties>
    <jaxb-api.version>2.3.0</jaxb-api.version>
</properties>

<!-- JAXB 2.3.0 for jdk9+ -->
<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>${jaxb-api.version}</version>
</dependency>
<dependency>
    <groupId>org.glassfish.jaxb</groupId>
    <artifactId>jaxb-runtime</artifactId>
    <version>${jaxb-api.version}</version>
</dependency>
<!-- JAXB needs javax.activation module (jdk9) -->
<dependency>
    <groupId>javax.activation</groupId>
    <artifactId>javax.activation-api</artifactId>
    <version>1.2.0</version>
</dependency>
bourgesl
источник
5
Спасибо, это работало для меня на Java 10. Тем не менее, использование одного свойства для номера версии 2.3.0для обоих jaxb-apiи jaxb-runtimeне является хорошей идеей. Время выполнения Glassfish в настоящее время равно2.3.0.1 API 2.3.0. Я предлагаю propertiesполностью исключить элемент из ответа и просто жестко закодировать каждый номер версии в каждом dependencyотдельно.
Василий Бурк
Моя рекомендация: <dependencyManagement>импортировать org.glassfish.jaxb:jaxb-bomспецификацию в какой-либо версии (последняя версия 2.3.0.1), а затем в фактическом <dependencies>разделе не указывать версию для jaxb-apiили jaxb-runtime. Номер версии будет взят из спецификации, что обеспечит их постоянную синхронизацию и совместное обновление.
AndrewF
2
JAXB 2.3. [0 | 1] больше не будет работать для Java 11! См github.com/eclipse-ee4j/jaxb-api/issues/78
col.panic
9

Мне нужно было заменить JAX-WS (java.xml.ws) и JAXB (java.xml.bind) для моего приложения на основе Spring Boot 2, и в итоге я получил следующие JAR (сборка Gradle):

// replacements for deprecated JDK module java.xml.ws
runtimeOnly 'javax.xml.ws:jaxws-api:2.3.0' // javax.xml.ws.* classes
runtimeOnly 'javax.jws:jsr181-api:1.0-MR1' // for javax.jws.* classes

// replacement for deprecated JDK module java.xml.bind
runtimeOnly 'javax.xml.bind:jaxb-api'
runtimeOnly 'org.glassfish.jaxb:jaxb-runtime:2.3.0.1'
runtimeOnly 'org.glassfish:javax.json:1.1.2'
runtimeOnly 'org.eclipse:yasson:1.0.1'

(Вам может понадобиться compileили другой объем, нам runtimeOnlyбыло достаточно.)

Я заметил, что https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-core описывается как «Старый», и использование этого ответа пошло и для org.glassfishоснованных материалов, которые также были введены org.eclipse.yasson.

Теперь это действительно грязная ситуация, она работает, но как можно быть уверенным, что это лучшая замена, верно?

virgo47
источник
мы также используем gradle, и я никуда не попал. Пытался перевести maven решения на gradle, но безуспешно. Ваш пример работает для меня (используется compile, хотя и не предоставлен, проект, который я пытаюсь перенести, использует vertx) Спасибо, что поделились, и, действительно, я также надеюсь, что скоро появятся некоторые разъяснения относительно gradle :)
Lars
Пожалуйста, обратите внимание, что ситуация развивается довольно быстро - совсем недавно я переместил другой проект в Spring Boot 2.2, где API-интерфейсы Jakarta более заметны, но нам все еще нужны реализации. Для этого я все еще использую org.glassfish. * Материал. Всякий раз, когда я использую проект Spring Boot, я склонен проверять их версии зависимостей и максимально соответствовать им (сменить текущую версию на нужную
virgo47
8

Похоже, что jaxws-ri транзитивно зависит от commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852, который, очевидно, можно найти в репозитории http://download.eclipse.org/rt/eclipselink/maven.repo.

theNikki1
источник
1
Вероятно, потому что это больше подходило для комментария, а не ответа. Несмотря на это, вы смогли решить проблему? Кажется, я не могу получить зависимость. mvn -U clean installпродолжает говорить Could not find artifact commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852.
Зил
1
Я не эксперт по Maven, но кажется, что он находит commonj.sdo: commonj.sdo: jar: 2.1.1.v201112051852, когда в pom.xml не объявлено ни одного хранилища. Если в pom.xml есть репозитории (например, spring-snapshot), нужно также добавить download.eclipse.org/rt/eclipselink/maven.repository , например <repository> <id> my-id </ id> <name> eclipse-repo </ name> <url> download.eclipse.org/rt/eclipselink/maven.repo </ url > </ repository> ps. Я бы добавил комментарий вместо ответа, если бы моя репутация была достаточно большой :)
theNikki1
2
Я мог заставить его работать, но мне также пришлось удалить зеркало из моего settings.xml. Однако после дальнейшей проверки я не могу воспроизвести, как это заменить устаревший пакет. Вместо этого я нашел эту зависимость, которая хорошо работает:<dependency> <groupId>javax.jws</groupId> <artifactId>jsr181-api</artifactId> <version>1.0-MR1</version> </dependency>
Зил
Я смог просто исключить посылкуsdo-eclipselink-plugin
Джозеф Луст
2

Просто незначительное изменение (улучшение) вышеупомянутых ответов - приведено здесь только для JAXB. Можно добавить зависимости с runtimeобластью действия и только в том случае, если это эффективно необходимо (т. Е. При сборке для запуска в JRE с версией> = 9 - здесь показан пример v11):

<profile>
        <id>when-on-jdk-11</id>
        <activation>
            <jdk>11</jdk>
        </activation>

        <properties>
            <!-- missing artefacts version properties -->
            <jaxb-api.version>2.3.1</jaxb-api.version>
            <jaxb-impl.version>2.3.2</jaxb-impl.version> <!-- one might let it the same with the jaxb-api.version -->
        </properties>

        <dependencies>
            <!-- runtime dependencies to avoid JAXB related CNF exceptions when running on Java 11 (e.g.: ClassNotFoundException: javax.xml.bind.annotation.XmlType) -->
            <dependency>
                <groupId>javax.xml.bind</groupId>
                <artifactId>jaxb-api</artifactId>
                <version>${jaxb-api.version}</version>
                <scope>runtime</scope>
            </dependency>
            <dependency>
                <groupId>org.glassfish.jaxb</groupId>
                <artifactId>jaxb-runtime</artifactId>
                <version>${jaxb-impl.version}</version>
                <scope>runtime</scope>
            </dependency>
        </dependencies>
    </profile>
Поль-Emil
источник
1

Я экспериментировал с большинством предложений, описанных выше, используя JDK 11.0.3, и не был успешным. Единственное решение, которое я в итоге нашел для работы, заключается в следующем. Возможно, есть и другие варианты, которые также работают, но кажется, что выбор версии имеет решающее значение. Например, изменение com.sun.xml.ws:rt на 2.3.2 приводит к тому, что модуль javax.jws больше не будет доступен.

    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
        <version>2.4.0-b180830.0438</version>
    </dependency>
    <dependency>
        <groupId>com.sun.xml.ws</groupId>
        <artifactId>rt</artifactId>
        <version>2.3.1</version>
    </dependency> 
Де Альберт
источник
0

Я нашел самый простой способ обойти JAXB-части этих проблем - использовать управление зависимостями в моей корневой помпе или в моей:

    <project ...>
      <dependencyManagement>
        <dependencies>
          <!-- ... -->
          <!-- Gone from jvm in java11 -->
          <dependency>
          <groupId>com.sun.xml.bind</groupId>
          <artifactId>jaxb-ri</artifactId>
          <version>2.4.0-b180830.0438</version>
          <scope>import</scope>
          <type>pom</type>
        </dependency>
        <!-- ... -->
      </dependencies>
    </dependencyManagement>
    </project>

И в модулях, которые терпят неудачу при компиляции на jdk11:

    <!-- ... -->
    <dependencies>
      <!-- Gone from jvm in java11 -->
      <dependency>
         <groupId>javax.xml.bind</groupId>
         <artifactId>jaxb-api</artifactId>
      </dependency>
      <dependency>
         <groupId>com.sun.xml.bind</groupId>
         <artifactId>jaxb-impl</artifactId>
         <scope>runtime</scope>
      </dependency>
      <dependency>
         <groupId>org.glassfish.jaxb</groupId>
         <artifactId>jaxb-runtime</artifactId>
         <scope>runtime</scope>
      </dependency>
      <!-- ... -->
    </dependencies>  
    <!-- ... -->

Кроме того, обновление версии org.jvnet.jaxb2.maven2:maven-jaxb2-pluginдо 0.14.0 решило все проблемы генерации jaxb для меня.

Джордж
источник
0

Я использую JDK 11 + муравей + плющ в моем весеннем проекте MVC. Я получаю ошибку пакет javax.jws не существует », поэтому я добавил javax.jws-api-1.1.jar в classpath, и это сработало! Просто скачайте jar с https://repo1.maven.org/maven2/javax/jws/javax.jws-api/1.1/javax.jws-api-1.1.jar и добавьте его в путь к классам в вашем build.xml

Шива
источник