相关链接

自从JSR-220专家小组将基于注解的依赖注入和Java持久化API作为Java EE 1.5的一部分引入以来，就可以使用专门的@PersistenceContext和@PersistenceUnit注解，将EntityManager或EntityManagerFactory注入到大多数Java EE组件中。

后来，我的JSR-299专家小组引入了一种全新的依赖注入方法，最终被命名为Java的上下文与依赖注入。最初非常具有争议性，但随着时间的推移，CDI已经成为Java EE平台——哦，我是说Jakarta EE——和其他技术的核心，这些技术现在采用了CDI作为基础组件模型，目前已经是第六版。

但在CDI 1.0时，我需要一种方法来弥合@PersistenceContext和CDI支持的@Inject注解之间的差距。而CDI本身又陷入了对立之中，我并不处于一个非常强大的政治地位，去请求EE平台小组重新定义他们当时几乎全新的依赖注入注解，以适应我们疯狂的新方向。

在Jakarta Persistence 3.2总结中，我有许多有趣的新话题要讨论，以至于我忘记提到一个重要的事情。

来自Substack的跨发帖子。

我职业生涯中最重要的一次经历是与来自Sun的Linda DeMichiel、TopLink的Mike Keith、Sybase的Evan Ireland等人合作，设计和编写Java持久化规范的第一版。

今天这项技术受到广泛认可，甚至包括曾经的批评者。但近年来，尽管规范更名为Jakarta Persistence，但规范并没有快速发展。直到现在才有所变化。在过去的一年左右的时间里，Oracle的Lukas Jungmann和我一直在努力推出长时间以来最大的持久化版本。

本文将重点介绍我们添加到Jakarta Persistence中的新功能。值得注意的是，许多工作都投入到了现有功能的语义澄清和规范中某些部分的改写，以提高清晰度和可读性。这是一个持续的工作。规范有超过500页；在不改变其意义的情况下重写这样的文本是一个缓慢而艰巨的过程。

在之前的一篇文章中，我谈到了Jakarta Data。两个规范的同步是一个进一步的优先事项。