jOOQ 3.16和Java EE vs Jakarta EE的简单介绍

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