23

Clearly the com.sun.xml.bind:jaxb-impl artifact is labelled "Old JAXB Runtime module" in the maven repository (see link below), and yet both of these artifacts are still getting new releases:

https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl

This answer Which artifacts should I use for JAXB RI in my Maven project? does not clarify the difference.

The accepted answer to both the above question and this one How to resolve java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException conclude that for Java 9+ you should use: org.glassfish.jaxb:jaxb-runtime

But I have code using com.sun.xml.bind:jaxb-impl and it appears to be working fine. So what do I lose or gain by moving to jaxb-runtime?

Even the latest (3.0.2 at the time I write this) version is available for the "OLD" jaxb-impl module. If Oracle isn't doing this anymore, who makes the com.sun.xml.bind:jaxb-impl artifact? What is it for? Why doesn't it share the Maven group coordinates with jaxb-runtime?

Is there any central location that clearly documents what the current state of affairs is with JAXB?

There is just so much confusion with JAXB now.

P.S. I need to remain compatible with Java 8 for the time being - so I can't go to 3.x yet, and 2.4.x appears to be an abandoned attempt at fixing the modularity that they foolishly broke when it was split out of the JDK.

swpalmer
  • 3,890
  • 2
  • 23
  • 31
  • 2
    I think confusion like this is a big contributor to why so many developers are still using Java 8. Upgrading to a new JDK was mostly trivial up to Java 8. If you start with 11 or later you are fine, but 11 represents a significant barrier when migrating from earlier versions. – swpalmer Feb 12 '22 at 21:13
  • Hey, I am just wondering if you ever found out more. Specifically I am looking for some central location where I can read about the current state of affairs with JAXB. – ConfusedUbuntist Jun 15 '22 at 20:07
  • @ConfusedUbuntist Nope... I haven't found any place that has a complete description of the state of JAXB. I just try to put together the pieces from digging through the eclipse-ee4j stuff. It's sparse and mostly undocumented. – swpalmer Jun 15 '22 at 22:49
  • That is too bad. Hopefully at some point, things will get at least some clear documentation. – ConfusedUbuntist Jun 16 '22 at 13:38

1 Answers1

32

The only difference between jaxb-impl and jaxb-runtime is packaging: jaxb-impl bundles istack/txw2 inside the jar, whereas jaxb-runtime provides them via separate dependencies.

Version Compatibility and the JakartaEE Migration

I've been trying to make sense of this for the last day, and it's incredibly confusing. Particularly when you're trying to avoid the java.xml.bind to jakarta.xml.bind migration. There's out of date information everywhere and some broken releases in the jaxb-impl 2.3.x release line.

Best I can tell, GlassFish was providing the JAXB reference implementation. It's since moved to EE4J, but releases continue from that project against both sets of coordinates. Appears that com.sun.xml.bind:jaxb-ri is where the latest full bundles are released:

https://github.com/eclipse-ee4j/jaxb-ri/

Having figured out that piece of history, the real mess is that none of the artifacts reflect the javax.xml.bind to jakarta.xml.bind move in their artifact coordinates, only in the versions. This means if you're in ecosystem where you need both to exist, you're going to have a bad time.

For instance, the 2.3.3 release changed from depending on javax.xml.bind:jaxb-api to jakarta.xml.bind:jakarta.xml.bind-api because at 2.x, the jakarta artifacts provide the javax.xml.bind packages. At version 3.0.0 it provides jakarta.xml.bind.

The implementations are the same at 3.0.0 which means while the earlier versions could happily exist at runtime, you have no way of resolving them both in build tools and conflict resolution is going to break legacy uses of javax.xml.bind APIs.

Allow javax.xml.bind and jakarta.xml.bind to coexist

For projects that need both APIs to coexist without migrating the legacy code:

  • For javax.xml.bind use com.sun.xml.bind:jaxb-impl:2.3.6. Ignore the 3.0.0 and later releases. Add an explicit dependency on javax.xml.bind:jaxb-api:2.3.1 so that you have a package providing the javax.xml.bind API
  • For jakarta.xml.bind use the latest org.glassfish.jaxb:jaxb-runtime. Ignore the releases earlier than 3.0.0

Runtime compatibility with jakarta.xml.bind

Use the tomcat-jakartaee-migration tool to rewrite classes for deployment.

For Gradle projects, you can use the gradle-jakartaee-migration-plugin, and get the benefit of capabilities and transforms at development time too.

Migrate to jakarta.xml.bind

You can use either of the coordinates for the runtime based on your preferences for packaging:

  • com.sun.xml.bind:jaxb-impl:4.0.0
  • org.glassfish.jaxb:jaxb-runtime:4.0.0

Both depend on jakarta.xml.bind:jakarta.xml.bind-api with the jakarta.xml.bind package namespace.

Danny Thomas
  • 1,879
  • 1
  • 18
  • 32
  • 6
    There is no question that the process of handing over JAXB was a complete disaster. It's till next to impossible to find the latest implementation jar - only the API jar is linked from any pages I could find. They've changed the implementation project and they have no useful links to anything. – swpalmer May 08 '22 at 18:30
  • 5
    Agreed, I haven't come across a bigger mess than this in the Java world off late. – Swapnil May 27 '22 at 18:07
  • 1
    I would not have a problem doing the java.xml.bind to jakarta.xml.bind migration, but I cannot even find any information on that. Based on your answer, it appears that you have at least some experience knowledge in that regard. If you could give a link or elaborate on that a bit further, I would really appreciate it. I have asked a separate question (https://stackoverflow.com/questions/72609324/what-needs-to-be-included-when-migrating-from-javax-xml-bind-to-jakarta-xml-bind) if it gets too off topic for this question. My wording in the liked question may be a little off due to confusion. – ConfusedUbuntist Jun 15 '22 at 20:45
  • 1
    It certainly does! Thanks very much! – ConfusedUbuntist Jun 20 '22 at 13:09
  • What is the difference between jakarta.xml.bind-api vs jaxb-impl ? – Rams Aug 03 '23 at 17:59
  • @Rams the API and implementation are split between two artifacts. The impl brings in the API transitively, but you'd depend directly on the API only if you had a library and you wanted to leave the choice of implementation up to the downstream consumer – Danny Thomas Aug 12 '23 at 03:49