GraalVM 19.3 支持的延迟 - 计划用于 Quarkus 1.2 - 这是原因
Quarkus 1.1.0.CR1 最受期待的功能之一是 GraalVM 19.3 支持。GraalVM 19.3 更改了很多内容（JDK 11 预览等），由于 Quarkus 和 GraalVM 之间的深度集成，这对我们来说是一次全有或全无的更新，因为我们无法同时支持 GraalVM 19.2 和 19.3。
在将 Quarkus 移植到 GraalVM 19.3 时，我们遇到了一些回归，有些是由于 Quarkus 未做正确的事情（我们已修复），有些是由于 GraalVM 回归（我们正与 GraalVM 团队合作解决）。GraalVM 的下一个微错误修复版本计划在 1 月中旬发布，因此任何变通方法都必须来自 Quarkus，通过编写替代方法。
尽管它并不漂亮，但最终结果足够稳固，我们决定发布 CR1 并支持 GraalVM 19.3。
然而，我们的 1.1.0.Final 已恢复到 GraalVM 19.2。相信我们，这是一个艰难的决定，特别是考虑到为 1.1 所做的所有准备工作。那么为什么会退步呢？
我们不想打破我们的承诺
Quarkus 的承诺之一是生态系统在任何 JVM 和 GraalVM 原生映像可执行文件上都能同样运行良好。并且您可以轻松地构建原生映像。
一些问题偏离了这一方向
-
一个并发问题随机出现 导致原生映像构建有时失败
-
Neo4J 扩展以及更广泛的 Neo4J 驱动程序支持在 GraalVM 19.3 中不再可用：https://github.com/oracle/graal/issues/1995
-
由于 https://github.com/oracle/graal/issues/1971，一些 Apache Camel Quarkus 集成测试也无法在原生映像模式下工作。虽然我们可以接受后者，但这也意味着它可能发生在您的任何应用程序中。
有了这些回归，我们已经举棋不定，并且已经采取了一些补救措施（见下文）。但我们发现另一个核心问题，它关系到 Quarkus 的承诺。
RSS (内存) 使用率回归
在发布 1.1.0.CR1 后，我们收到报告称启动时的 RSS 使用量不如以前。RSS 测量进程的驻留大小，即进程消耗的所有内存。
我们的测量显示，Quarkus 1.1 与 GraalVM 19.2 在首次请求/响应后为 14MB。而 GraalVM 19.3 将其提高到 63MB。由于 Quarkus 的内存消耗是一个核心价值，我们决定回滚并争取更多时间。
Quarkus 和 GraalVM 团队正在进行调查以解决此问题。如果您有兴趣了解更多信息，请参阅Quarkus 问题和其配套的 GraalVM 问题。一旦我们彻底解决了这个问题，Quarkus 在 GraalVM 19.3 上的路径将畅通无阻。
那么现在呢？
好吧，首先，请准备好将您的 GraalVM 安装降级到 19.2.1 以便即将发布的 1.1.0.Final。
我们正在全力以赴，在我们的下一个版本中带来 GraalVM 19.3 支持（也希望包括 GraalVM JDK 11 支持）。并发问题已在 GraalVM master 中修复，这让我们专注于底层问题。我们的目标是帮助 GraalVM 团队理解并修复这些问题，并将所有这些回溯到 GraalVM 19.3.1。
但更根本的是，我们不希望这种情况再次发生：这么晚才发现这些问题是令人不快的。为了能够更早地发现这些问题，我们正在设置一系列 CI 作业，以检查整个 Quarkus 生态系统（核心扩展 + quickstarts + Camel 扩展 + 其他外部扩展）是否与 GraalVM master 兼容。这有点挑战性，因为它是（GraalVM）master 上的（Quarkus）master 上的（Apache Camel Quarkus）master，但这是唯一的前进方向。我们已经有了 CI 作业，它已经在使用 Quarkus master 和 GraalVM master 测试我们的 QuickStart 套件。
我们还计划在此 CI 管道中添加一些 RSS 使用量检查。有趣的是，我们有一个不同的 CI 作业在测试 RSS，但它的报告因 NPE 而失败。🤦。墨菲定律真是无处不在。
我们希望您能理解我们谨慎的立场以及延迟一个月左右的计划。
与此同时，一个全新的 Quarkus 版本即将发布，其中包含许多令人兴奋的新功能，敬请期待！
