286

Java 9 deprecated six modules that contain Java EE APIs and they are going to be removed soon:

  • java.activation with javax.activation package
  • java.corba with javax.activity, javax.rmi, javax.rmi.CORBA, and org.omg.* packages
  • java.transaction with javax.transaction package
  • java.xml.bind with all javax.xml.bind.* packages
  • java.xml.ws with javax.jws, javax.jws.soap, javax.xml.soap, and all javax.xml.ws.* packages
  • java.xml.ws.annotation with javax.annotation package

Which maintained third-party artifacts provide those APIs? It doesn't matter how well they provide those APIs or which other features they have to offer - all that matters is, are they a drop-in replacement for these modules/packages?

To make it easier to collect knoweldge, I answered with what I know so far and made the answer a community wiki. I hope people will extend it instead of writing their own answers.


Before you vote to close:

  • Yes, there are already some questions on individual modules and an answer to this question would of course duplicate that information. But AFAIK there is no single point to learn about all of these, which I think has a lot of value.
  • Questions asking for library recommendations are usually considered off-topic, because "they tend to attract opinionated answers and spam", but I don't think that applies here. The set of valid libraries is clearly delineated: They have to implement a specific standard. Beyond that nothing else matters, so I don't see much risk for opinion and spam.
Naman
  • 27,789
  • 26
  • 218
  • 353
Nicolai Parlog
  • 47,972
  • 24
  • 125
  • 255
  • 9
    You can mostly find all of those getting moved under https://github.com/javaee and links to few specifics at [JEP 320: Remove the Java EE and CORBA Modules](http://openjdk.java.net/jeps/320) – Naman Jan 11 '18 at 09:59
  • 1
    See also this 2018-05-14 article in InfoWorld, [*Java roadmap: Eclipse’s Jakarta EE enterprise Java takes shape*](https://www.infoworld.com/article/3269210/java/java-roadmap-eclipses-jakarta-ee-enterprise-java-takes-shape.html) by Paul Krill. Subtitle: The Eclipse Foundation outlines the 39 projects that will make up the new cloud-native, microservices-friendly enterprise Java effort, and how GlassFish will evolve – Basil Bourque Jul 19 '18 at 18:31
  • 2
    From JDK 11 it has been removed. If you are using jdk 9 or above it is better to add the dependency directly rather then using the "--add-modules java.xml.bind" kind of stuff – Anver Sadhat Oct 29 '18 at 07:36

11 Answers11

320

Instead of using the deprecated Java EE modules, use the following artifacts.

JAF (java.activation)

JavaBeans Activation Framework (now Jakarta Activation) is a standalone technology (available on Maven Central):

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

(Source)

CORBA (java.corba)

From JEP 320:

There will not be a standalone version of CORBA unless third parties take over maintenance of the CORBA APIs, ORB implementation, CosNaming provider, etc. Third party maintenance is possible because the Java SE Platform endorses independent implementations of CORBA. In contrast, the API for RMI-IIOP is defined and implemented solely within Java SE. There will not be a standalone version of RMI-IIOP unless a dedicated JSR is started to maintain it, or stewardship of the API is taken over by the Eclipse Foundation (the transition of stewardship of Java EE from the JCP to the Eclipse Foundation includes GlassFish and its implementation of CORBA and RMI-IIOP).

JTA (java.transaction)

Stand alone version:

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

(Source)

JAXB (java.xml.bind)

Since Java EE was rebranded to Jakarta EE, JAXB is now provided by new artifacts:

<!-- 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>

<!-- Alternative runtime -->
<dependency>
    <groupId>org.glassfish.jaxb</groupId>
    <artifactId>jaxb-runtime</artifactId>
    <version>2.3.3</version>
    <scope>runtime</scope>
</dependency>

JAXB Reference Implementation page.

The alternative runtime was brought up by @Abhijit Sarkar since com.sun.xml.bind:jaxb-impl has been deprecated.

schemagen and xjc can be downloaded from there too as part of a standalone JAXB distribution.

See also linked answer.

JAX-WS (java.xml.ws)

Reference implementation:

<!-- 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>

Standalone distribution download (contains wsgen and wsimport).

Common Annotations (java.xml.ws.annotation)

Java Commons Annotations (available on Maven Central):

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

(Source)

starball
  • 20,030
  • 7
  • 43
  • 238
Nicolai Parlog
  • 47,972
  • 24
  • 125
  • 255
  • what to do in case if a module reads `jax-ws` from both jdk and `com.sun.xml.ws` dependency? – nllsdfx May 16 '18 at 14:14
  • 1
    I'm not sure what exactly you're asking. Which module reads jax-ws? If you have _java.xml.ws_ in the module graph and _com.sun.xml.ws:jaxws-ri_ on the class path, the latter will be ignored (because of [split packages](https://blog.codefx.org/java/java-9-migration-guide/#Split-Packages)). – Nicolai Parlog May 16 '18 at 14:17
  • Well I want to use `com.sun.xml.ws:jaxws-ri` instead of `java.xml.ws` in my module because the latter is deprecated and will be removed. And I added the dependency to my pom file and the error "module xyz reads package 'javax.xml.ws' from both 'java.xml.ws' and 'java.xml.ws'" appeared. – nllsdfx May 16 '18 at 14:27
  • It looks like the module _java.xml.ws_ is resolved after all, maybe due to an `--add-modules` or because some other modules requires it. Can you open a new question, so we can take a look at it? – Nicolai Parlog May 16 '18 at 14:44
  • have a look please at https://stackoverflow.com/questions/50392459/java-10-replacement-for-java-xm-ws-conflict – nllsdfx May 17 '18 at 13:17
  • What about the *java.se.ee* module itself? Is there a replacement for that in maven? – ZhekaKozlov May 27 '18 at 16:01
  • @ZhekaKozlov Not as far as I know, but would be easy to create oneif you need it. – Nicolai Parlog May 27 '18 at 20:04
  • Concerning the JAXB replacements. Both jaxb-core and jaxb-impl contain the same package name "com.sun.xml.bind" and will cause "split package" error in a JPMS modular application. It will not work if both are present. – Terran Oct 02 '18 at 20:52
  • 1
    That's true. Two details: (1) If no explicit module (i.e. one with a module declaration) depends on JAXB, you can still place them on the class path, where split packages don't matter. (2) The command line option [`--patch-module`](https://blog.codefx.org/java/five-command-line-options-hack-java-module-system/#Adding-Classes-To-Modules-With--patch-module) can mend the split. – Nicolai Parlog Oct 02 '18 at 21:23
  • @Terran The split package problem is no more actual. There is now a single Maven module `jaxb-runtime` instead of two modules `jaxb-core` and `jaxb-impl`. – ZhekaKozlov Nov 18 '19 at 03:45
  • Need this as well [com.google.code.findbugs:jsr305](https://mvnrepository.com/artifact/com.google.code.findbugs/jsr305/3.0.2) in case we have missing `javax.annotation.Nullable` – Zain Qazi Apr 30 '20 at 19:40
  • this appears to be the most update to date answer... so I'd like to add an additional question, is there a right way with maven to add these jars, but only if it's on java 11+ meaning that building/running (in dev) on java 8 would still be functional without having to be concerned for which class/jar is actually being used. Obviously if you have a build artifact you'd have to filter or not depending on what you're building for, but just running in dev mode would be different. – xenoterracide Jan 19 '21 at 18:41
  • What will the future JAXB maven coordinates be? I'm confused because the Jakarta page says `com.sun.xml.bind:jaxb-impl`, but @AbhijitSarkar says it's deprecated? – Reto Höhener May 26 '21 at 08:53
  • Note that for JAXB you can't use the "runtime" Maven scope as you'll need to "requires org.glassfish.jaxb.runtime;" in your module-info file. Without it, the Java runtime won't have access to the JAXB Context when using JPMS. It'll work if you don't use JPMS, though. – AndrewBourgeois Jan 29 '23 at 12:58
  • Thanks for the answer. I got one more question, though: In my project I have `javax.xml.` packages. To be precise, there are `javax.xml.parsers`, `javax.xml.transform` and `javax.xml.validation` packages. How do I upgrade them to be from `jakarta.` package and not from `javax.` When I use the above mentioned dependencies for JAXB I get compilation error `Cannot resolve symbol` being showed from Inttelij IDEA. Thanks for the answers :) – Arthur Eirich Sep 01 '23 at 14:36
35

JAXB (java.xml.bind) for JDK9

Working perfectly in my desktop applications on 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>
Toparvion
  • 799
  • 2
  • 9
  • 19
bourgesl
  • 371
  • 2
  • 3
  • 6
    Thanks, this worked for me on Java 10. However, that use of a single property for version number `2.3.0` for both `jaxb-api` and `jaxb-runtime` is not a good idea. The [Glassfish runtime is currently at `2.3.0.1`](https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime) while the API remains at `2.3.0`. I suggest dropping the `properties` element entirely in the Answer, and just hard-code each version number in each `dependency` separately. – Basil Bourque Jul 17 '18 at 22:40
  • My recommendation: in ``, import the `org.glassfish.jaxb:jaxb-bom` BOM at some version (latest now is 2.3.0.1), and then in the actual `` section, do not specify a version for either `jaxb-api` or `jaxb-runtime`. The version number will be grabbed from the BOM, which will ensure they are always in sync and get upgraded together. – AndrewF Nov 08 '18 at 03:26
  • 3
    JAXB 2.3.[0|1] will not work for Java 11 anymore! See https://github.com/eclipse-ee4j/jaxb-api/issues/78 – col.panic Dec 12 '18 at 09:46
13

I needed to replace JAX-WS (java.xml.ws) and JAXB (java.xml.bind) for my Spring Boot 2 based application and ended up with these JARs (Gradle build):

// 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'

(You may need compile or other scope, runtimeOnly was enough for us.)

I noticed that https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-core is described as "Old" and using this answer went for org.glassfish based stuff that brought in org.eclipse.yasson as well.

Now it's really messy situation, it works, but how should anyone be sure it's the best replacement, right?

virgo47
  • 2,283
  • 24
  • 30
  • we're also using gradle and I didn't get anywhere. Tried to translate the maven solutions to gradle but no success. Your example works for me (used compile though, not provided, the project I try to migrate is using vertx). Thanks for sharing and indeed, i also hope there will be some clarifications regarding gradle soon :) – Lars Sep 20 '18 at 11:14
  • Please, note that situation evolves quite quickly - just recently I moved another project to Spring Boot 2.2 where Jakarta APIs are more prominent, but we also still need implementations. For that I still use org.glassfish.* stuff. Whenever I use Spring Boot project, I tend to check their dependency versions appendix and conform to that as much as possible (change current to version you need): https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-dependency-versions.html – virgo47 Jun 15 '20 at 17:56
8

It seems that jaxws-ri depends transitively from commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852 which apparently can be found from repository http://download.eclipse.org/rt/eclipselink/maven.repo

theNikki1
  • 151
  • 1
  • 6
  • 1
    Probably because it was more suited for a comment rather than an answer. Regardless, were you able to fix the problem? I don't appear to be able to retrieve the dependency. `mvn -U clean install` keeps saying `Could not find artifact commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852`. – Zyl Jul 02 '18 at 15:42
  • 1
    I'm not maven expert, but it seems that it is finding commonj.sdo:commonj.sdo:jar:2.1.1.v201112051852 when no repositories are declared in pom.xml. If there are repositories in pom.xml (like spring-snapshot) one must also add http://download.eclipse.org/rt/eclipselink/maven.repository, for example my-id eclipse-repo http://download.eclipse.org/rt/eclipselink/maven.repo ps. I've would have added comment instead of answer if my reputation was big enough :) – theNikki1 Jul 03 '18 at 08:11
  • 2
    I could get it to work but I had to also remove a mirror from my settings.xml. After further inspection however I cannot reproduce how this is a replacement for the deprecated package. Instead I found this dependency which works nicely: ` javax.jws jsr181-api 1.0-MR1 ` – Zyl Jul 04 '18 at 15:31
  • 1
    I was able to just exclude the package `sdo-eclipselink-plugin` – Joseph Lust Dec 11 '18 at 22:41
5

I'm using jdk 11 + ant + ivy in my spring mvc project. I was getting error "package javax.jws does not exist" so I added javax.jws-api-1.1.jar to classpath and it worked! Just download the jar from https://repo1.maven.org/maven2/javax/jws/javax.jws-api/1.1/javax.jws-api-1.1.jar And add it to your classpath in your build.xml

Alternatively add it to your pom.xml:

<dependency>
  <groupId>javax.jws</groupId>
  <artifactId>javax.jws-api</artifactId>
  <version>1.1</version>
</dependency>
abarisone
  • 3,707
  • 11
  • 35
  • 54
Shiva
  • 81
  • 2
  • 5
  • 1
    You can include it properly through Maven's dependency resolution system: ` javax.jws javax.jws-api1.1 ` and it actually resolves the "javax.jws" classes correctly. – msteiger Aug 07 '20 at 06:59
4

Just a minor variation (improvement) on the above answers --- exemplified here for JAXB only. One can add the dependencies with the runtime scope and only if this is effectively needed (i.e. when building for running in a JRE with version >= 9 --- here v11 is exemplified):

<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>
paul-emil
  • 41
  • 1
  • 3
3

If you have this issue in Talend (7.x for example), you can add in the Default POM.xml of the project:

<dependencies>
    <dependency>
        <groupId>javax.xml.soap</groupId>
        <artifactId>javax.xml.soap-api</artifactId>
        <version>1.4.0</version>
    </dependency>
</dependencies>

Tested with :

  • AdoptJDK 8.0.275.1-hotspot : OK
  • AdoptJDK 11.0.9.101-hotspot : OK
  • AdoptJDK 15.0.1.9-hotspot : KO (but It is another issue: Incompatible conditional operand types Exception and TDieException)
  • Zulu-8.50.0.1017: OK
  • Zulu-11.43.1015 : OK
David KELLER
  • 464
  • 4
  • 8
2

I have experimented with most of the suggestions described above using JDK 11.0.3 and have been not been successful. The only solution that I eventually found to work is the following. Perhaps there are other options that also work but it appears that the selection of version is critical. For example, changing com.sun.xml.ws:rt to 2.3.2 causes module javax.jws to no long be available.

    <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> 
Des Albert
  • 281
  • 2
  • 5
  • 17
2

If you have the same problem add the below dependency to pom.xml

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

Then use JAVA 8 as an alternate JRE. For further details refer to this video, which worked for me.

Max von Hippel
  • 2,856
  • 3
  • 29
  • 46
Dinithi
  • 518
  • 5
  • 17
2

It's indeed a real pain still going through this as of 2022! I tried many above suggestions, but only could only get it to work with below dependencies.

<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-core</artifactId>
    <version>2.3.0.1</version>
</dependency>
 
<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.3.1</version>
</dependency>
 
<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-impl</artifactId>
    <version>2.3.1</version>
</dependency>
  
<dependency>
    <groupId>org.javassist</groupId>
    <artifactId>javassist</artifactId>
    <version>3.25.0-GA</version>
</dependency>

Note: Don't be tempted to update the dependencies, just leave it that way, and it works for me.

Wale
  • 1,644
  • 15
  • 31
1

I found the easiest path to get around the JAXB parts of these issues was to use dependency management in my root pom or in my bom:

    <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>

And in the modules that fail compilation on 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>  
    <!-- ... -->

Also, updating the version of org.jvnet.jaxb2.maven2:maven-jaxb2-plugin to 0.14.0 solved all the jaxb generation issues for me.

George
  • 309
  • 3
  • 6