jaxb-impl 和 jaxb-runtime 之间有什么区别?

swp*_*mer 30 java jaxb

显然,com.sun.xml.bind:jaxb-impl 工件在 Maven 存储库中被标记为“JAXB 运行时模块”(请参阅​​下面的链接),但这两个工件仍在发布新版本:

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

这个答案在我的 Maven 项目中,哪些工件应该用于 JAXB RI? 没有阐明差异。

上述问题和这一问题的公认答案如何解决 java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException 的结论是,对于 Java 9+,您应该使用: org.glassfish.jaxb:jaxb-runtime

但我有使用 com.sun.xml.bind:jaxb-impl 的代码,它似乎工作正常。那么,迁移到 jaxb-runtime 会带来什么损失或收益呢?

即使是最新版本(我撰写本文时为 3.0.2)也可用于“旧”jaxb-impl 模块。如果 Oracle 不再这样做,那么谁制作了 com.sun.xml.bind:jaxb-impl 工件?它是做什么用的?为什么它不与 jaxb-runtime 共享 Maven 组坐标?

是否有任何中心位置可以清楚地记录 JAXB 的当前状况?

现在 JAXB 存在很多混乱。

PS 我暂时需要保持与 Java 8 的兼容性 - 所以我还不能使用 3.x,而 2.4.x 似乎是一次放弃的尝试,旨在修复他们在分离出来时愚蠢地破坏的模块化性。 JDK。

Dan*_*mas 44

jaxb-impl和之间的唯一区别jaxb-runtime是打包:jaxb-impl将 istack/txw2 捆绑在 jar 内,而jaxb-runtime通过单独的依赖项提供它们。

版本兼容性和 JakartaEE 迁移

最后一天我一直在试图理解这一点,但它非常令人困惑。特别是当您试图避免java.xml.bind迁移时jakarta.xml.bind。2.3.x 发行版中到处都是过时的信息和一些损坏的版本jaxb-impl

据我所知,GlassFish 提供了 JAXB 参考实现。此后它已转移到 EE4J,但该项目的发布仍在针对两组坐标继续进行。似乎这com.sun.xml.bind:jaxb-ri是最新完整捆绑包的发布位置:

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

弄清楚那段历史后,真正的混乱是,没有一个文物反映了在其文物坐标中的javax.xml.bind移动jakarta.xml.bind,仅在版本中反映了移动。这意味着,如果您处于需要两者共存的生态系统中,那么您的日子将会很糟糕。

例如,2.3.3 版本从“依赖”更改为“依赖javax.xml.bind:jaxb-apijakarta.xml.bind:jakarta.xml.bind-api,因为在 2.x 中,jakarta工件提供了javax.xml.bind包。在 3.0.0 版本中它提供了jakarta.xml.bind.

3.0.0 的实现是相同的,这意味着虽然早期版本可以在运行时愉快地存在,但您无法在构建工具中解决它们,并且冲突解决将破坏javax.xml.bindAPI 的遗留使用。

允许 javax.xml.bind 和 jakarta.xml.bind 共存

对于需要两个 API 共存而不迁移旧代码的项目:

  • 用来。javax.xml.bindcom.sun.xml.bind:jaxb-impl:2.3.6忽略 3.0.0 及更高版本。添加显式依赖项,以便您拥有提供API 的javax.xml.bind:jaxb-api:2.3.1javax.xml.bind
  • 用于jakarta.xml.bind使用最新的org.glassfish.jaxb:jaxb-runtime. 忽略 3.0.0 之前的版本

与 jakarta.xml.bind 的运行时兼容性

使用tomcat-jakartaee-migration工具重写部署类。

对于 Gradle 项目,您可以使用gradle-jakartaee-migration-plugin,并在开发时获得功能和转换的好处。

迁移到 jakarta.xml.bind

您可以根据您的打包偏好使用任一运行时坐标:

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

两者都依赖于jakarta.xml.bind:jakarta.xml.bind-apijakarta.xml.bind命名空间。

  • 毫无疑问,移交 JAXB 的过程完全是一场灾难。找到最新的实现 jar 几乎是不可能的——只有 API jar 是从我能找到的任何页面链接的。他们改变了实施项目,并且没有任何有用的链接。 (8认同)
  • 同意,我最近在 Java 世界中还没有遇到过比这更大的混乱。 (5认同)
  • @Rams API 和实现分为两个工件。impl 传递性地引入 API,但只有当您有一个库并且您希望将实现的选择留给下游消费者时,您才会直接依赖于 API (2认同)