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
usecom.sun.xml.bind:jaxb-impl:2.3.6
. Ignore the 3.0.0 and later releases. Add an explicit dependency onjavax.xml.bind:jaxb-api:2.3.1
so that you have a package providing thejavax.xml.bind
API - For
jakarta.xml.bind
use the latestorg.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.