在我们之前的谈话中，我们重点关注了他们认为是实现其使命的以下步骤的技术变化。除了速度和云原生性之外，开发人员的喜悦和对反应式和命令式编码风格的支持是Quarkus 使命宣言的一部分，开发人员体验(DX) 和对生产力的关注也是之前每个主要版本的重要组成部分。为了弄清楚 3.0 版本是否会遵循这一传统，InfoQ 继续与 Andersen 进行了对话。

InfoQ：Quarkus 2 提供了持续测试，作为您对愉快的开发者体验的承诺的一部分。有没有为3.0准备的东西？

Andersen： Quarkus 具有三个可以提高开发人员生产力的功能：

持续测试

开发服务

热重载体验

它们使您无需复杂的设置即可探索和尝试，重新启动并仍然应用TDD。接下来，我们专注于改进它们的集成以及视觉体验。

Dev UI 是围绕Qute 模板概念构建的，它是提供开发相关信息的“tiles”。尽管添加内容很容易，但需要大量重复，而且有些工作流程根本无法实施。我们打算拥有更通用的结构，并使用更先进的客户端技术来获得更丰富的体验。

为了改进更新流程，我们探索了 CLI 插件机制的想法，以允许集成外部提供的工具以在开发过程中提供帮助。

InfoQ：Kotlin 越来越受欢迎是否反映在 Quarkus 的用户习惯上？斯卡拉怎么样？

Andersen：每个报告的问题都需要一个复制器项目：Java 处于领先地位，而 Scala 只有几个补丁（例如 Scala 3）。Kotlin 增加了牵引力，足以分配专门的工程时间来改善体验。例如，改进了热重载。此外，我们还探索了改进 Kotlin 中协程和反应式代码使用的方法。

InfoQ：命令式编程和反应式编程怎么样？

Andersen：从技术上讲，每个人都间接地使用了 Reactive：框架是建立在 Reactive 核心之上的。用户可以选择使用 SmallRye Mutiny 或 Kotlin Coroutines 命令式（也称为阻塞）或反应式编写业务逻辑。在可预见的未来，这三种型号都将面世。您应该根据应用程序的类型以务实的方式处理它，而不是一种意识形态或偏好。例如，一个主要由事件驱动的应用程序更倾向于响应式，而传统的 CRUD REST 微服务可能仅将其用于特定调用，大约占 15-30%。

从 2.x 开始，Quarkus 的默认 REST 堆栈是反应式的，但用户可以为其业务逻辑选择命令式。

一个类似的热门话题是虚拟线程的使用。Loom 项目的输出承诺具有命令式的简单性和类似于反应式的性能，而没有反应式编程的心理开销。我们对虚拟线程的早期支持有限- Java 开发工具包中的限制使虚拟线程无法成为直接替代品。

InfoQ：Quarkus 3.0 是否进一步实现超音速启动时间承诺？

安徒生：我们一直致力于提高绩效。但是，我们最近遇到了瓶颈——改进并没有像我们预期的那样出现。当我们意识到其他非 JVM 解决方案没有类似问题时，我们开始调查。这导致 Francesco Nigro（重新）发现了一个与 JVM 优化检查相关的长期错误instanceof。我们对 Quarkus 使用的库应用了许多更新以减少影响。我们与 OpenJDK 团队合作对其进行了修复，并希望也能向后移植到未来的 Java 版本中。

我们的目标是支持io_uring，这是一种使用现代操作系统内核的功能，它允许在内核和应用程序之间共享环形缓冲区，从而避免昂贵的复制操作。它是改善响应时间和减少延迟的游戏规则改变者。

最后，升级到 Hibernate 6 使我们能够放弃 Hibernate 5 中与启动和本机图像改进相关的解决方法。对于 Hibernate 6，我们可以使用“普通”版本，它带有自己的一组新功能和特定于 Hibernate 的改进。

不仅仅是功能和工具，Quarkus 的第三个里程碑带来了对文档的更改以及遵循Diataxis框架原则。而且，为了为现有用户进行迁移，还提供了迁移工具。鼓励开发人员进行试验并与团队分享反馈。