VMware 对 Spring 6 和 Spring Boot 3 再进行十年大修
在Spring One 2021 上，VMware 透露了计划于 2022 年 10 月发布的 Spring 6 如何为下一个十年准备框架：它将需要 Java 17 和 Jakarta EE 9，为 Java 模块和本机编译提供一流的支持，将可观察性融入到Spring，并删除过时的功能和第三方集成。Spring Boot 3 将使用 Spring 6，但还没有发布日期。
Spring Framework 今年将不会有新的主要版本，这是自 2010 年以来的第一次，展示了这次大修的规模。不过，即将发布的次要版本将支持 Java 17，而 Spring Boot 2.xy 版本系列仍将获得2021 年 11 月和 2022 年 5 月的主要版本。
最近的开发人员调查显示较早采用较新的云原生 Java 框架，例如 Quarkus 和 Micronaut。这些框架生成具有低内存使用率和快速启动时间的本机应用程序。Spring 6 可能被视为 VMware 对这些竞争框架的回应。
Spring 6 将具有通常重叠的维护发布分支。但是“强烈鼓励 Spring Framework 6 用户加入我们的功能发布流，不要期望在 6.0.x 上停留很长时间，而是让 6.1、6.2 等升级成为他们常规使用模型的一部分。”
发布节奏也可能从一年一次变为半年一次，就像 Spring Boot 已经做的那样。
要求 Java 17 不像现在听起来那么激进；到 Spring 6 发布时，Java 19 将发布。Jakarta EE 9 作为基线打破了与新包命名空间的向后兼容性，但允许 Spring 跟上；一些 Spring 依赖项已经支持 Jakarta EE 9（例如 Tomcat 10 或 Jetty 11），而其他依赖项要到明年才会支持（例如 Hibernate ORM 6）。jakarta
Spring 6 预计将使用 Java 平台模块系统 (JPMS)，并允许开发人员使用 JPMS 编写 Spring 应用程序。
Spring Native现在通过 GraalVM 提供 Spring 应用程序的本地编译。随着计划于 2021 年 11 月 19 日发布的 0.11 版本将进一步改进，该版本将依赖于 GraalVM 21.3 和 Spring Boot 2.6。但 Spring Boot 3 将原生编译与入门配置和构建包无缝集成，取代 Spring 6 中的 Spring Native。
Spring Boot 3 可能不会立即提供所有Spring Initializr库的本地编译。与其他框架的情况一样，目前没有简单的方法可以知道任何给定的 Java 库是否在本机模式下工作。
Spring Observability 是 Spring 6 中的一个新项目，它建立在从Spring Cloud Sleuth 中吸取的经验教训之上。它使用 Micrometer 记录指标，并通过 OpenZipkin 或 OpenTelemetry 等提供程序提供跟踪。与基于代理的可观察性不同，Spring 可观察性将在本机编译的 Spring 应用程序中工作。并且作为核心 Spring Framework 的一部分，它也将更有效地提供更好的信息。
VMware 提供了一些计划删除的过时功能示例，即按名称/类型自动装配 setter、一些 FactoryBean 安排和“某些与 Web 相关的选项”。EJB 和 JAX-WS 是第三方集成，可能会从 Spring 6 中删除。
Spring 6 的第一个里程碑计划于 2021 年底发布，候选版本计划于 2022 年 7 月发布。VMware 邀请社区就其 Spring 和 Spring Boot 计划提供反馈。
InfoQ采访了 VMware 的高级通讯经理Kristen Strem，他是 Spring 团队的联络人，询问有关 Spring Framework 6 和 Spring Boot 3 的问题。
InfoQ：第 6 版为 Spring 框架又准备了十年。为什么这是必要的，为什么是现在？
**Kristen Strem：**我们看到了 Java 生态系统的一个重大转折点，该行业最终接受了下一代 Java 并将 JDK 8 转移到遗留系统的遗留状态。我们预计 JDK 17 将在这一转变中发挥关键作用，提供具有许多累积 Java 语言、API 和 VM 增强功能的有吸引力的新长期支持生成 - 比 JDK 11 LTS 更重要，后者主要被用作普通的 JDK 8 替代品出于支持政策的原因。此外，不仅 JDK 17 是新一代 LTS，我们还期待即将发布的 JDK 功能版本（例如 Project Loom）中的更多关键优势，我们打算在保留 JDK 17 基线的同时选择性地支持它。最终，我们仍将支持 JDK 版本，直到 6.x 系列中的 JDK 29 LTS。
InfoQ：您将 Spring Framework 6.x 功能发布与 OpenJDK 发布模型进行了比较。这是否意味着一旦新版本 6.x 发布，您将停止为以前的版本分支生成版本？
**Strem：**在开源维护版本方面，我们会保持近年来的模式，像往常一样重叠维护分支。OpenJDK 发布模型为如何将主要功能（如 Project Loom 支持）整合到 6.x 功能版本而不是新的主要框架版本提供了灵感。此外，我们可能会在核心框架级别提供更频繁的 6.x 功能发布，不仅加入 OpenJDK，还加入 Spring Boot，每年发布两次功能迭代。最后但并非最不重要的一点是，强烈鼓励 Spring Framework 6 用户加入我们的功能发布流，不要期望在 6.0.x 上停留很长时间，而是让 6.1、6.2 等升级成为他们常规使用模型的一部分。
InfoQ：您展示了 Spring 6 开发人员如何在 Kubernetes 中快速重新加载和调试他们正在运行的应用程序。这需要Tanzu应用平台吗？如果是这样，您是否计划将其提供给每个 Kubernetes 安装？
**Strem：**您不需要任何特定于 Tanzu 的技术来支持 Kubernetes 中应用程序的重新加载和调试。Spring Boot 从 v1.3 开始附带了一个 devtools 模块，它与 Kubernetes 配合得很好。通常，您需要围绕要使用的工具以及如何配置这些工具做出一些决定。Dave Syer 在今年的 Spring One上发表的“在 Kubernetes 上使用 Spring Boot 进行内循环开发”演讲中对此进行了很好的概述。
当然，Tanzu 应用平台的部分价值在于，我们可以提供与我们熟悉的与 Spring 兼容的工具的合理集成，并且我们可以自动化很多事情，这样开发人员就无需担心它们。这是我们的许多客户想要的，您可以在今年的SpringOne 主题演讲中看到自动化正在发挥作用。
InfoQ：包括 Spring 在内的许多框架都使用 GraalVM 进行本地编译。您如何看待 Spring 与这些框架合作以改进整个 Java 社区的本机编译？例如，您提到了Spring One的 GraalVM 团队针对 Java 库和基准测试的GraalVM 兼容性存储库。
**Strem：**从第一天开始，Spring 团队的重点就是通过与 GraalVM 团队的深入合作来帮助成熟原生 Java 生态系统。本机构建工具允许通过 Gradle 和 Maven 插件构建和测试本机可执行文件，这是一个很好的化身。它由 Spring 和 GraalVM 团队发起，对 JUnit 项目做出了一些贡献。最近 Micronaut 团队联手，类似的合作对于 Java 生态系统将非常有价值。
Spring 和 GraalVM 团队在如何使原生 Java 生态系统更具可持续性和可维护性方面拥有共同的愿景，还允许在原生配置项目上进行深入协作，这应该提供指南和工具，以在各种框架之间共享原生配置。请注意，这种努力是通过利用 GraalVM 本地支持的最新改进来实现的：本地测试、本地配置改进、构建时内联等。
最后，每个框架都应该提供自己的“秘密武器”是完全没问题的。但是，如果没有 Java 工具和库的更多共享支持，原生 Java 生态系统就无法持续下去，作为 Spring Boot 3.x 工作的一部分，我们将继续投入大量精力与更广泛的生态系统进行这种协作。一流的原生支持。
InfoQ：在 4 月份，Juergen Hoeller 写道，他们正在考虑为 Spring Framework 6“在代码库中引入模块信息定义”。这是否意味着 Spring Framework 6 将为编写 Java 提供开箱即用的支持应用程序与 Java 平台模块系统？
Strem： Spring Framework 6 确实有望为所有核心框架模块引入模块信息描述符，对核心 Java 模块的依赖性最小，从而使 JDK 的
jlink工具能够为 Spring 设置构建自定义运行时映像。可选的第三方库和某些配置策略可能存在限制，因此尚不清楚这种显式模块使用在 Spring 用户中的流行程度。直到现在，我们还没有收到很多关于它的请求，尽管人们对最近的 Java 版本有很多兴趣。
提供相关 Spring One 会议的视频和幻灯片：Spring 6、Spring Native和Spring Observability。
