Замена устаревших модулей 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 нет единого смысла, чтобы узнать обо всем этом, что я думаю, имеет большую ценность.
  • Вопросы с просьбой дать рекомендации по библиотекам обычно считаются не по теме, потому что «они, как правило, привлекают взвешенные ответы и спам», но я не думаю, что это применимо здесь. Набор допустимых библиотек четко разграничен: они должны реализовывать определенный стандарт. Кроме этого, ничего больше не имеет значения, поэтому я не вижу большого риска для мнения и спама.

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>

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.

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


мы также используем 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.


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>

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.