Java Hibernate ORM与GraalVM本机映像编译兼容吗？

根据文档，GraalVM项目中的本机映像编译器在动态代理方面存在一些限制。由于Hibernate广泛使用代理，它能在提前编译的项目中正常工作吗

这个项目似乎表明它可以，但我的理解主要是基于一句谚语

Hibernate ORM现在甚至可以在编译为GraalVM本机映像时工作-只需确保使用Quarkus构建应用程序

如果我不想（或不能）使用Quarkus怎么办？是否可以使用使用Hibernate的GraalVM（和SubstrateVM）编译本机映像应用程序

Quarkus实际上是如何启用/支持Hibernate的？

（免责声明：我是通过创建Quarkus扩展使Hibernate ORM在GraalVM本机映像上工作的人之一。我还领导Hibernate研发团队。）

谢谢你给我这个机会写一点历史：）

最初我们没有使用Quarkus，因为它还不存在

我最初的原型只是修补Hibernate ORM，堆积了许多编译器开关，以传递给本机映像工具，用bash脚本进行硬编码，直到我的演示应用程序开始工作

这种方法的问题在于，许多这样的标志实际上依赖于Hibernate ORM的内部知识、域模型的细节、配置细节，甚至更多

我开始记录这些事情，但它变得复杂和毛茸茸的；不仅不同方面相互依赖；此外，我的演示应用程序相当简单，而实际应用程序的情况必然会变得更加复杂。。。我认为我们不可能写出一份既通俗又“易懂”的好文件

对于终端用户来说，让事情简单化的另一种选择是“在您可能使用的所有这些类上启用反射”，但我有点喜欢优化，这会创建更大、更臃肿的二进制文件，而不是只包含应用程序真正需要的所有内容

因此，我们的团队决定编写一个工具来自动处理这些细节。。它成为了一种构建工具，可以分析应用程序，找出最佳的交换机。我们没有只关注Hibernate ORM，而是创建了“扩展”的概念，它也知道如何在其他库中使用相同的技巧，这样您就可以从更复杂的应用程序中获得高度优化的二进制文件，这些应用程序使用的是受支持的库的组合，而不仅仅是Hibernate

显然，这是必要的，因为不同的库可能有冲突的需求，并且每个其他库的编译器标志和最终用户代码的组合需要组合在一组一致的兼容标志中

这就是Quarkus如何成为一种东西：）

要了解其工作原理的详细信息，我建议阅读指南和源代码：

我还从高层次概述了它在公开演讲中的工作原理；有一张来自英国Devxx的好唱片

我的演讲专门讨论了Hibernate ORM；我没有太多时间详细介绍它所做的所有事情，但在阅读实际代码了解详细信息之前，它应该是一个很好的介绍

如果我不想（或不能）使用Quarkus怎么办？是否可以使用使用Hibernate的GraalVM（和SubstrateVM）编译本机映像应用程序

这是一个公平的问题-当然有可能，但Quarkus团队很想知道为什么

Quarkus所做的所有工作大多只是构建时间；当然，由于这是一个非常年轻的项目，在这个阶段它可能会受到限制，但是如果您需要对其他任何东西的支持，那么在构建脚本中对其核心（或扩展）进行贡献应该比硬编码复杂的编译器标志更容易。不仅如此，Quarkus社区正在成为一个讨论如何解决任何可能受到Graal限制的障碍的好地方

Hibernate ORM的所有最复杂的补丁都已合并到Hibernate上游存储库中，因此所有重要的补丁都包含在任何最新版本中

假设您想远离Quarkus（我不建议这样做，但假设您想学习…），您仍然需要修补反射规则，而且Quarkus确实限制了一些功能，最值得注意的是一些细节仍然是“正在进行中”，或者我们认为人们不应该再使用的东西：）

具体来说，我和我的队友都不是线程绑定课程的超级粉丝。除非有人提出一个很好的理由，否则我不会实现对它的支持：请打开一个功能请求，或者理想情况下帮助为它和补丁提出一个很好的理由

---

如果您想知道，Quarkus实际做了什么来构建本机图像，并与其创建者一起阅读转录本（或观看视频）：

我记得：

• 在编译时解析所有注释查找和实体解析
• 准备一些带有“静态”初始化字段的实例。准备好的实例存储在映像中，并准备在启动时仅在堆上分配
• 如果需要，在编译时生成“代理”
• 基本上Quarkus（作为gralvm的“插件”）会“在应用程序实际连接到数据库时启动应用程序”。然后它获取内存快照并将其嵌入到jar/native文件中
• Quarkus也接触了一些其他库，它们做“禁止”的事情（封闭世界假设）

这将启用“热代码重新加载”，它实际上会在“眨眼”的时间内重新启动整个应用程序。它使用更少的内存和其他好东西

---

PS：这里有Quarkus的小介绍：

从Quarku浏览