VMware 发布了 Spring Framework 6和 Spring Boot 3。在 Spring Framework 5发布5 年后，这些新版本开始了 Spring 新时代的生态系统。Spring Framework 6需要 Java 17和 Jakarta EE 9.最近发布的 Jakarta EE 10兼容。它还具有跟踪和指标功能 Micrometer 嵌入可观察性。Spring Boot 3需要 Spring Framework 6.内置支持使用 GraalVM 原生镜像静态预先编译（AOT）构建原始可执行文件。这两个新版本框架的更多细节可以在 InfoQ 在这份报告中找到。
InfoQ 采访了这两个新版本的框架 Java Champion、VMware 的 Spring 开发者布道师Josh Long。VMware 的 Spring Framework 项目负责人Juergen Hoeller还回答了其中一个问题。
InfoQ：作为一名 Spring 开发者布道师，你会发表演讲，编写代码，发表文章和书籍，并操作播客。那你的一天是怎么过的呢？
Josh Long：这很难说！我的工作需要我与各种各样的人交流，面对面或通过互联网，所以我永远不知道我会在哪里，也不知道我会专注于什么。但一般来说，我的目标是促进生态系统的发展。也就是说，我想了解他们的应用场景，并推动他们找到问题的解决方案。假如这需要我和 Spring 我很高兴团队沟通或贡献代码。如果我需要发表演讲，录制播客，写一些文章或一本书或制作视频，我也会这么做。
InfoQ：VMware 从多个来源获取关于 Spring 反馈：会议、用户组、问题跟踪器Stack Overflow、Slack、Reddit、Twitter 等等。但满意度高的用户通常什么也不说，抱怨最多的人可能无法回应本质问题。那么，VMware 如何收集用户反馈并安排优先级？
Long：这是一个很好的问题：一切最终都会落在后面 GitHub 上。我们特别关注 StackOverflow 标签，并尽力回应它们。但是如果在那里发现的话 bug，最终会落到 GitHub 上。GitHub 这是参与这个项目的好方法。我们试着让它变得简单，比如为那些想要参与贡献的新人创造标签，让他们从我们可以接受的地方开始。当然，GitHub 这不是问答的好地方——所以我们使用它 Stackoverflow。我们非常依赖它 GitHub，因此，即使在团队内部，我们也会向自己的项目发送提取请求，并使用此工作流。
InfoQ：Spring 下面有很多项目。VMware 必须让 Spring 用户知道所有相关的事情。VMware 如何知道 Spring 用户不知道能教他们什么？
Long：简单地说，我们不知道，但我们可以猜测。我们花了大量精力开发新的、新的、最新的和最好的项目，并不断更新基本的东西。你不会相信我为一些项目做了多少次第一步之类的事情。我们也很清楚，登录我们门户网站的人可能是长期用户，但可以通过其他方式找到 Spring 的人对 Spring 可能知之甚少。因此，要不断推出开始第一步的介绍性内容。有时候开始的第一步变化够大，最基本的东西变得很新颖。
InfoQ：Java 遗留应用程序通常使用旧版本 Java 和框架。微服务架构使开发人员能够以较低的风险引入新的技术栈。你认为这是真的吗？ Java 展示新特点和新版本的好机会？或者更像是对的 Java 因为开发人员可以尝试威胁 Java 竞争对手，如.NET、Go、JavaScript 或 Python？
Long：威胁？相反，如果在其他编程语言中，Java 如果表现不好，最好暴露出来，这样才能促进 Java 向前发展。而且，说实话，Java 所有方面都不可能是最好的。微服务意味着我们可以在有意义的场景中使用它 Spring 和 Java，不会有 Java 和 Spring 当你不能提供最好的解决方案时，你会感到困难。不要问我是什么样的场景，因为我真的不知道……
InfoQ：Spring 5增加了对 Kotlin 显式支持。你现在估计有多少百分比？ Spring 用于开发 Kotlin？
Long：但是 Kotlin 是 Spring Initializer 使用第二多语言。
InfoQ：Scala 从未获得 Spring 这种显式支持。你觉得为什么？
Long：有的！早在2012年，我们就有一个叫做 Spring Scala 的项目。我们真的希望它能成功。在我们发布 Spring Scala 以前，我们甚至有一个 Scala 的 Spring Integration DSL。我们试过，但似乎没有一个社区希望它成功。这是遗憾。如今，随着反应和函数编程的兴起，我认为 Java 和 Scala 社区之间的共性比以往任何时候都大。
InfoQ：Spring 5还添加了反应应用程序。现在你是反应应用程序的支持者，甚至写了一本书。是什么让反应应用对你如此有吸引力？
Long：我喜欢反应编程。它给我们带来了三个显著的好处：1。用于表达系统状态转移的一种 DSL——系统的脆弱性问题通过回压、加班、重试等机制得到强有力的解决。这种简洁的 DSL 简化构建系统的过程，你最终得到的是为所有场景提供的抽象。2.一种用于编写多线程并发代码的方法 DSL——并发代码的线程和状态管理逻辑没有那么多麻烦。3.能够优雅地编写代码，使运行时更好地伸缩线程(即每秒处理更多请求)。
InfoQ：哪些问题或应用程序最适合反应开发？
Long：如果反应抽象适合你的领域，并且你想学习一些新的东西，那么反应编程可以用于所有的工作负写更可伸缩、更安全（更强大）和更一致的代码有什么问题？
InfoQ：反应开发不适合哪些场景？
Long：反应开发要求代码的编写范式发生一些变化。 Loom 项目，一个开关可以给你一些可伸缩性的好处。如果你对学习这个新范式不感兴趣，也不需要反应编程的好处，那么它对你没有意义。
InfoQ：对反应开发的常见抱怨是认知负荷和调试难度的增加。他们抱怨的问题是 Spring Framework 6和 Spring Boot 三中也会有吗？
Long：我不知道我们是否在那里 Spring Boot 三中直接解决了这些问题。然而，通常的机制仍然有效！用户可以在反应管的各个部分设置断点。它们可以使用 Reactor Tools 从管道中的所有线程中捕获堆栈跟踪信息。它们可以使用.log()和.tap()操作符获取流经管道的数据信息等。Spring Boot 三是显著改进——Spring 现在支持通过 Micrometer Metrics 和 Micrometer Tracing 捕获指标和跟踪信息。Reactor 甚至在反应管道中提供 Micrometer Observation 抽象支持。
InfoQ：工具支持(例如 IDE 框架的成功有多重要？至少，有经验的用户通常会绕过导游和实用工具，直接修改配置文件和代码。
Long：这个问题很有趣。我已经努力证明工具是为了 Spring Boot 开发人员的经验并不是很重要。事实上，自从 Spring Boot 自发布以来，可以支持任何使用 Java IDE 开发新的应用程序。你不需要 IntelliJ IDEA 终极版、对 Spring XML 名称空间的支持甚至不需要 Eclipse 中的 Java EE 和 WTP 支持来 Spring Boot。假如你的工具支持 public static void main、Apache Maven 或 Gradle，以及所需的 Java 版本，万事大吉！Spring Boot 有些地方可能会从工具中获得好处，比如 application.properties 和 application.yaml。但即使在这里，你也不一定需要工具——Spring Boot 的 Spring Boot Actuator 这些文件中定义的所有属性都可以提供模块。也就是说，即使你需要自己编辑一切，你也不会觉得麻烦。好的工具会给人一种整个按钮都放在你面前的感觉。谁不喜欢呢？为了实现这一目标，我们做了很多工作，并尽可能地改进它 Eclipse 和 VS Code(并扩展到大多数支持 Eclipse Java Language Server 开发者体验的工具)。在我看来，好的工具对迁移现有代码更为重要。新的 Jakarta EE API 这是一个很好的例子。Jakarta EE 取代了 Java EE——javax.*所有类型都迁移到下面 jakarta.*下。Eclipse 基金会的工作人员付出了巨大的努力，使熟悉这些新类型的过程尽可能简单，但仍有许多工作要完成。我想，你选择的 IDE 也会让这些变得更容易。
InfoQ：这是自2010年以来的第一次 Spring Framework 更新不是在最后一次重大发布后一年，而是两年后(5.3版本于2020年发布)。Spring Framework 6似乎有两年的开发时间，而不是一年。是什么导致花了这么长时间？
Long：我甚至没注意到！说实话，我感觉到了 SpringFramework 已经开发了两年多了。这个版本令人难以置信的忙乱！迁移到 Java17很容易迁移到 JakartaEE 对我们来说是一个挑战。首先，我们必须清理所有的支持 Spring Boot 库中的依赖项。然后，我们一个接一个地处理所有的库，直到一切都变绿。这是一项艰苦而缓慢的工作，我很高兴完成了。然而，这些工作是用来使用的 Spring Boot 开发人员可能微不足道。我们还做了很多关于可观测性的工作，重点是 Micrometer 现在支持跟踪，跟踪和指标有一个统一的抽象，即 Observation。现在让我们学习一些背景故事。在 Spring Boot 2.x 我们介绍了它 Micrometer 捕获指标并将其保存到各种时间序列数据库中 Netflix Atlas、Prometheus 等。Spring Framework 依赖 Micrometer，Spring Boot 依赖 Spring Framework，Spring Cloud 依赖 Spring Boot，支持分布式跟踪 Spring Cloud Sleuth 依赖 Spring Cloud。因此，指标位于抽象栈的底层，分布式跟踪位于顶层。这种抽象栈在很大程度上没有问题，但这意味着我们有两个不同的指标和跟踪抽象。这也意味着，如果不引入循环依赖，Spring Framework 和 Spring Boot 不支持分布式跟踪。Spring Boot 3中的变化——Spring Framework 依赖 Micrometer，Micrometer 通过简单统一的抽象支持跟踪和指标。最后，使用 GraalVM Native Image 进行提前（AOT）编译工作在 Spring Framework 6（2022年 11月 15日发布)正式落地。这项工作从2019年开始就以某种形式进行了。第一个叫做 Spring Native 我们在这个项目中验证了实验研究项目 Spring Boot 2.x 和 Spring Framework 5.x 各种功能。这些工作成果已经包含在内 Spring Framework 6和 Spring Boot 3中。
InfoQ：就像去年宣布的那样，Spring Framework 6.0和 6.免费支持时间会更短。 Spring 5.2的 与27个月相比，两者都下降了20%(下降到21.5个月)。相比之下，Spring Boot 3.0的免费支持期仍为一年。为什么？
Long：2021年底，我们规范了计算方法。我们已经为开源版提供了12个月的免费支持。每个项目都可以根据发布周期和社区需求进行扩展，但所有项目至少需要12个月的开源支持和12个月的额外商业支持。对我们来说，在主要版本中进一步扩展支持最后一个次要版本是正常的(就像我们在一样 SpringFramework5.3.x )。需要注意的是，支持时间的标准化发生在2021年底。从那时起，我们就没有发布过任何主要或次要的东西 Spring Framework 版本。Spring Framework 6将是新标准下的第一个。Juergen Hoeller：Spring Framework 6.0和 6.商业支持时间也较短。开源版有缩短开源版的支持时间来支持商业支持。更确切地说，所有的时间都变短了——人们希望更快地升级到最新的6.x 就像他们最近升级得更快一样 JDK 一样。在这方面，Spring Framework 5.x 依然紧密配合 JDK8使用风格-你可以留在你身边 JDK 级别和 JavaEE 级别上”。Spring Framework 6.x 尽可能紧跟 JDK 17+和 Jakarta EE 9+(两者都比以前频繁发布)，并相应调整发布理念。
InfoQ：Spring Boot 3支持 GraalVM Native Image 的 AOT 编译器。这样可以获得启动速度更快、内存使用更少、容器镜像更小、更安全的原生 Java 应用程序。这将使云计算的哪些领域 Java 与 Go 等待竞争对手处于更平等的地位？
Long：我不知道我是否应该 Java 与 Go 一起讨论 Go 表现如何，Java 编程语言不是最节省内存的语言。这导致了编程语言。 Java 错过了物联网和无服务器等机会。 GraalVM Native Image 进行 AOT 可以保持编译 Java 可伸缩性和生产力引以为傲。
InfoQ：原生 Java 云计算的哪些领域不会起到很大的作用？
Long：我不知道。我感觉 GraalVM Native Image 可能是 JRE 的替代品。事实上，GraalVM 也打开了新门。现在开发人员可以用了 Spring Boot 编写自定义 Kubernetes 控制器。您还可以编写特定于操作系统的客户端二进制文件，如 CLI（hello，Spring Shell！）。
InfoQ：原生 Java 缺点是管道建设缓慢、复杂，工具支持少，可观察性降低。管道建设的缺点似乎是不可避免的——AOT 编译需要更长的时间，不同的操作系统需要不同的可执行文件。然而，你认为从中期和动态的角度来看 Java 相比，原生 Java 工具支持和可观察性如何？
Long：IntelliJ 已经为调试 GraalVM 原生镜像提供了极好的支持。我不认为大多数人会失去它 Java 可移植性引以为傲，感到悲哀。毕竟，大多数应用程序都在 Linux 主机上的 Linux 操作系统 Linux 运行在容器中。有一个很棒 GitHub Action，您可以使用它进行交叉编译，构建过程可以在多个操作系统上运行，并生成特定于这些操作系统的可执行文件。你可以使用 Buildpacks（Spring Boot 例如：mvn -Pnative spring-boot:build-image）等工具在 macOS 或 Windows 容器镜像构建和操作容器镜像。GraalVM 由于可观测性支持受到影响， Java 代理不能很好地可执行文件中很好地运行。但是，前面提到的 Micrometer 支持可以避免许多限制，并产生更详细的结果。
InfoQ：说到可观性，这是 Spring 6的另一个主要功能。它基于日志记录、指标和跟踪，包括 Micrometer 的。Java 为什么已经有很多可观选项？ Spring 再加一个？为什么是现在？
Long：Java 并没有像 Micrometer 做了这么多事。我们没有加入另一个——我们在增强一个现有的。Micrometer 已成为实际标准。许多其他库已经将其集成到表面指标中：RabbitMQ Java 客户端Vert.x?HibernateHikariCPApache CamelReactorRSocketR2DBCDS-ProxyOpenFeignDubboSkywalkingResilience4J（进行中）Neo4J
InfoQ：除了直接读取数据文件外，如何查看和分析？ Spring 6和 Spring Boot 3的可观测数据？
Long：Micrometer 提供一系列和 Graphite、Prometheus、Netflix Atlas、InfluxDB、Datadog 集成指标工具的能力。它可以与 OpenZipkin 同时使用等分布式跟踪工具。它还与 OpenTelemetry（“OTel)集成，所以你可以与之相处 OTel 服务通信。
InfoQ：Spring Boot 3.发布时不会为所有项目和图书馆提供全面的本土资源Java还有可观察性支持。那我怎么知道呢？ Spring Boot 3应用程序能否支持原始应用程序 Java 并提供完整的可观察数据？
Long：这只是更长更大旅程的开始。 GraalVM Native Image 几乎每天都天都在增加。虽然没有明确的清单，但你应该知道所有的主要清单 Spring 所有项目都在提供支持。这是我们的首要任务。看看我们Spring AOT抽烟测试，看看哪些核心项目已经验证。
InfoQ：Java 你最兴奋的功能是什么？
Long：我对即将到来的三个项目非常兴奋：Loom 项目、Leyden 项目和 Panama 项目。Loom 项目为 JVM 带来轻量级绿色线程，并承诺提高可伸缩性。Leyden该项目似乎为应用程序开发人员提供了更多的约束和优化参数 JVM 应用程序。其中一个更引人注目的限制似乎是 GraalVM 原生镜像。Panama 项目希望对外函数的访问最终像 Python、Ruby、PHP、.NET 和语言一样容易。这三个方面的努力将得到推动 Java 进入新领域。
InfoQ：如果你能对 Java 做出改变，你想要什么？
Long：结构化的 lambda！我想要真的 lambda。目前，lambda 语法糖几乎是一种单一抽象接口的语法糖 lambda 必须遵循单一抽象方法（SAM）接口，如 java.util.function.Function。这在 Java 加入我喜欢的 var 关键词以前很好，但现在从美学上看有点不愉快，因为它需要告诉编译器给定的 lambda 遵循哪个接口。下面是 Kotlin 一些代码：
val name =”Karen”//常规String类型变量val myLambda:(String)-> Int ={ name -> name.length }///以字符串为参数，返回整数lambda
复制代码
下面是 Java 等效代码：
var name =”Karen”;var myLambda = new Function(){@Overridepublic Integer apply(String s){return s.length()；
复制代码
有几种方法可以解决这个问题：
var name =”Karen”;Function myLambda = s -> s.length();
复制代码
这就是我所说的美学，让人觉得不开心:要么两行都不能用 var 一开始，要么放弃 lambda 简洁。这个问题能解决吗？可能不会。这是严重的问题吗？当然不是。总的来说，Java 这是一种美妙的语言。大多数语言应该很幸运，因为它们已经到了 Java 年龄，但语法没有它那么奇怪！
InfoQ：你希望 Spring 或 Spring Boot 做出什么样的改变？
Long：这很难说！我希望我们能够恢复和更新 Spring Rich(一个已经失效的框架)用于构建桌面 Swing 驱动客户端应用程序。目前 Griffon 是唯一能解决这个问题的框架。因为 Spring 我本可以在这方面做得很好，尤其是现在它已经深度集成了 GraalVM Native Image 支持。当然，这可能只是利基的应用场景。
嘉宾简介：
Josh Long（推特账号@starbuxman）是自2010年以来的第一个 Spring 开发者布道师。Josh 是 Java Champion，着有6 本书（包括 O’Reilly 的《云原生 Java：使用 Spring Boot、Spring Cloud 和 Cloud Foundry 设计弹性系统和《Reactive Spring》），录制了许多流行的培训视频(包括和 Spring Boot 联合创始人 Phil Webb 使用合作 Spring Boot 构建微服务)，他也是一名开源贡献者（Spring Boot、Spring Integration、Spring Cloud、Activiti 和 Vaadin 等)，一个播客和 YouTube 博主。
Karsten Silz 在欧美做了23年的全栈 Java 开发者（Spring Boot、Angular、Flutter）。2004年，他在美国联合创办了一家软件产品初创公司。Karsten 领导产品开发13年，在公司成功销售后离开。自2003年以来，他一直是承包商。2020年，他作为首席技术官在英国联合成立 SaaS 初创企业“Your Home in Good Hands”。
原文链接：
https://www.infoq.com/articles/josh-long-spring-6/
