一股浪潮在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的未来将最终尽可能地摆脱这些依赖，或者把它们移到可选的插件模块中。