大约八个月前，我开始了非常令人激动的旅程。这段旅程才刚刚开始，今天我比开始时更加兴奋。昨天，我们宣布了 Quarkus，对我来说，它代表着三件事
-
Java处于一个新的交叉点
-
Java在容器平台和无服务器领域卷土重来
-
开发者体验为王
一个新的范式转变
Java在过去有过几次范式转变。其中两个对我影响深远，因为我参与了其中
-
Java生态系统被开源所占领
-
Java引入了
@Annotations并极大地改变了编程模型（XML又是谁？）。一些框架忽略了它（它们已经消失了），一些框架拥抱了它，并创建了新的注解原生框架。这场革命改变了Java生态系统。
我相信我们现在正站在这些交叉点之一。Java正在拥抱即时编译（AOT），这将改变一切。对于那些不知道的人来说，GraalVM 和特別是 Substrate VM 正在打开这扇门。
GraalVM很棒，因为它将Java代码的启动时间缩短到毫秒级（或者我们更喜欢称之为首次响应时间）和 10+ MB 的常驻集大小（RSS）。当你测量Java中的内存时，你需要注意两件事
-
堆大小（这就是
-Xmx东西） -
和非堆大小（这是JVM需要保持其结构和其他事情的大小，简而言之，不是我们的应用程序数据）
这两者加起来构成了总内存消耗，这很好地由RSS表示。RSS在现实生活中很重要，尤其是在容器中。当你超过内存限制时，Kubernetes会正确地杀死你（有点粗鲁，但它告诉你不要超过限制，你不是一个人）。
GraalVM带来了低RSS和启动时间。这很好，但GraalVM也有其阴暗面。Java的动态特性受到了极大的限制（运行时类加载、反射、代理等）。在实践中，这意味着90%的Java生态系统没有改变就无法工作。
因此，Java生态系统必须适应。它必须接受在启动时做更少的魔术。好消息是，我们可以在构建时做大多数事情 :)。
Quarkus确实为框架提供了一个基础设施，以拥抱构建时元数据发现（如注解），声明哪些类需要在运行时反射，在构建时启动，并且通常免费（或至少便宜）提供大量GraalVM优化。
如果我要夸张一下，Quarkus使得GraalVM对框架开发者（以及用户，稍后说明）变得可用。
但是等等，为什么我关心内存和启动时间
人们拥抱敏捷性。为了做到这一点，他们拥抱新的即时部署平台，如Kubernetes或其替代品。想法是，您只需点击一下按钮或接近这一点，就可以部署一个或多个应用程序实例。结合微服务，这也有助于敏捷性，您可以在这些平台上部署许多许多实例。这种模式的极端是服务器端，仅部署最小函数：您可能会想象200个函数来做一件好事。
当您部署20倍或200倍的Java进程时，Java占用100MB、200MB或更多固定成本的想法是禁止的。特别是在函数即服务方面，2秒或更多意味着酷孩子们不得不放弃Java。
不再是这样。在我们的测试中，我们发现使用GraalVM编译的Quarkus应用程序具有非常良好的请求/s/MB数。我们关心请求/s/MB，因为在Kubernetes等部署平台上部署第二个应用程序实例非常容易，大致可以将请求/s翻倍。您不是扩展一个进程，而是扩展进程。
哦，还有Quarkus在您的旧OpenJDK HotSpot上的内存和启动时间也相当令人印象深刻。这让我想到下一个要点。
开发者体验
所有这些都很有趣，但最终，开发者是国王。节省几个MB，但失去一个愉快、高效、易于使用的体验是不够的。
好消息是，当您可以从冷启动开始，在热启动时甚至更快地启动完整应用程序时，您面前就打开了无数有趣的机会。
我们行动起来！还有更多！Quarkus具有出色的开发者体验
- 真正快速的测试套件运行
-
您的测试套件将运行得非常快，足够快，以至于像模拟服务以加快速度、组件的懒加载启动、使用应用程序的子集进行测试等技巧变得不再需要（或更少常见）。测试套件运行时检查Facebook的日子已经屈指可数了。
- 实时重新加载
-
我们有一个实时重新加载模式，无需任何配置或IDE技巧。在您的IDE中保存，它编译，然后您就可以刷新浏览器查看结果。您的应用程序已经被您重新部署，时间在秒以下。使用如此短的反馈循环，编写涉及UI和数据库更改的更改非常容易。
-
添加新的Hibernate
@Entity，保存⇒它已部署，是的，包括数据库模式更改 -
添加新的REST端点，一个CDI bean，保存⇒它已部署
-
更改
application.properties或类似index.html的资源文件中的配置⇒Boom，它已部署
-
最好的部分是我们重新部署了完整的应用程序，因为Quarkus启动非常便宜。不需要进行字节码的热替换或任何其他操作。
- 统一且具有偏见的平台
-
虽然我们重用标准和流行的框架，但我们希望有一个非常易于使用的体验。这意味着一个配置文件，而不是两个，而不是每个技术一个。这体现在Quarkus的每个地方，但让我给您举一个例子：不需要
persistence.xml。如果您想要，我们支持它。但默认情况下，我们检测您的数据库设置从application.properties，并为您解决其余部分。 - Panache带来的生产力
-
我们也考虑了80%的使用场景，因为这些场景应该是尽可能简单的，因为毕竟你每天都在做这些。对于这些场景，我们采用了更加戏剧性的方法，提供了一个基于常规技术的、有见地、简洁易读的方法。其中的一个典范是我们基于JPA和Hibernate ORM开发的简化模型。这完全是可选的，但如果您接受这种方法，您的代码将会更加简单和精简。我们在内部使用代码名“Panache”来指代这些方法。“Panache”意味着张扬的方式和风格。请查看使用Panache的Hibernate示例以了解这一方法的第一个示例。
