一股浪潮在Java生态系统中荡漾开来。它便是将javax 改名为jakarta 包名。现在，尽管咱们都在抱怨，都在摇头，由于企业法律和工程利益之间的抵触，但终究是时候继续前进，了解这对jOOQ的详细意义。

jOOQ总共有3个Java EE依靠项：

  • JAXB- 这是jOOQ中适当普遍的依靠联系，也是咱们在这篇博文中首要评论的一个。它被jOOQ的运行时和代码生成模块所运用，现在它不是可选的（至少API需求存在）。
  • JPA- 这是jOOQ中一个可选的依靠。jOOQ运行时能够在必定程度上映射到JPA实体，而代码生成器能够在必定程度上生成实体注释。
  • Bean验证- 这不是一个正式的依靠联系。代码生成器能够生成Bean验证注释，仅此而已。

在jOOQ 3.16中，一切这3个依靠都被搬迁到Jakarta EE中，问题#9641。这种变化在某种程度上是不可避免的，但考虑到Spring Boot 3.0也将进行搬迁，并暂时将jOOQ从其开发构建中移除（见spring-boot#28821），我认为咱们现在不妨进行搬迁。

搬迁对jOOQ详细意味着什么？

JAXB

JAXB是最大的Java EE依靠，也是咱们无法容易脱节的。至少在API中不能。现在有3种流行的XML格式是运用JAXB进行marshalled和unmarshalled的：

  • 代码生成装备
  • 设置
  • 信息模式导出

详细来说，代码生成装备的JAXB注释非常有用，由于用户能够轻松地将XML文件与程序化的代码生成装备合并。另外，由Etienne Studer供给的流行的gradle-jooq-plugin 第三方奉献，经过对注释的反省而作业。

由于JDK 11删除了JAXB的API和完成，造成了紊乱，咱们现已完成了自己的”MiniJAXB “完成，满足了咱们有限的JAXB需求。这样，即便classpath上没有JAXB完成，也能够用jOOQ作业。但是API仍然是强制性的，正如这儿所评论的，咱们好像不能容易脱节它。

JPA

咱们的 [DefaultRecordMapper](https://www.jooq.org/doc/latest/manual/sql-execution/fetching/recordmapper/)能够在必定程度上映射到JPA实体。这使得从JPA到jOOQ的搬迁愈加容易，也能够为那些喜爱的人运用根据注解的映射，而无需重新发明咱们自己的自定义注解。

一起，代码生成器能够被装备为在生成的POJO类上生成JPA注解，首要是为了相同的DefaultRecordMapper ，远比把生成的代码作为实际的实体运用要好得多。

这两个功用一直是有争议的，这整个新的Java EE与Jakarta EE的争辩可能是有利于终究删除它们的一个转折点。这个决议还没有做出，但这个范畴必定不是jOOQ产生最大价值的当地。

Bean验证

咱们没有完成Bean验证，但在jOOQ中对生成的POJO类生成一些Bean验证注解一直是一个低垂的果实，只是为了用一些众所周知的元数据来充实你的POJO，比如说，@Size 。由于咱们对这个Jakarta EE项目没有硬性依靠（只要你生成的代码有，而且只要在你挑选参加的情况下），这个问题实际上并没有受到向Jakarta EE搬迁的影响。

向后兼容还是不兼容？

因此，鉴于咱们必须在jOOQ 3.16或最迟在jOOQ 3.17中采取行动（鉴于Spring Boot的立场能够了解），问题是：

  • 咱们是否应该暂时供给对Java EE和Jakarta EE APIs的支撑？
  • 咱们是否应该继续前进，忘掉Java EE？
  • 咱们是否应该放弃对集成的支撑？

明显，放弃对JAXB的支撑不是一个选项（尽管对JPA和Bean Validation是这样）。支撑两者并行的作业，有两个子选项：

  • 发送一个包含两种依靠联系的单一工件
  • 发送多个工件，每个依靠都有一个。

前者是自找麻烦。对jOOQ来说不是。对jOOQ来说，支撑这两个API是很简单的，但是在一切jOOQ用户的classpaths上有这两个API是很糟糕的，会在客户项目中造成许多问题。

发送多个工件将是洁净的，并答应用户自己决议做什么。这也是许多其他项目所做的，例如Hibernate。但是那些这样做的人对Jakarta EE项目有很强的依靠性，例如Hibernate对JPA。关于Hibernate来说，分裂成两个发行版是合理的。但对jOOQ来说就不相同了，它对这些API的运用微乎其微（乃至对JAXB）。

此外，jOOQ现已有很多的发行版，你能够在下载页面看到：https://www.jooq.org/download/versions。

咱们有：

  • jOOQ开源版
  • Java 17的jOOQ试用版
  • jOOQ Java 11试用版
  • jOOQ Java 8试用版
  • jOOQ Java 17专业版
  • jOOQ Java 11专业版
  • Java 8的jOOQ专业版

(注意，假如你想知道的话，有很好的理由不运用多版本的罐子。)

现在幻想一下，假如一切这些版本都需求另一个维度的Jakarta EE依靠性，那会有多紊乱。这是不现实的。

所以，咱们咬紧牙关，继续前进。从jOOQ 3.16开端，Java EE现已消失，Jakarta EE是咱们的依靠，在需求的当地。

未来

这一切的紊乱再次告知咱们，依靠联系是一种痛苦。关于像jOOQ这样的库来说，它们更是一种痛苦（由于它给用户项目带来的痛苦）。咱们有一个（几乎）零依靠的政策，但咱们自己不能彻底遵守，包含由于JDK决议在Java 6（我想）参加JAXB后，在Java 11中再次扔掉它。当jOOQ开端时，JAXB好像并不是一个依靠项，但它实际上是依靠项。

所以，jOOQ的未来将终究尽可能地脱节这些依靠，或者把它们移到可选的插件模块中。