为什么(如何)从 Java 8/11 迁移到 Java 21，从 Spring Boot 2 迁移到最新的 Spring Boot 3.2 ？

最新推荐文章于 2024-04-16 22:04:31 发布

xuejianxinokok

最新推荐文章于 2024-04-16 22:04:31 发布

阅读量1.4k

点赞数 22

分类专栏： java 文章标签： java spring boot python

本文链接：https://blog.csdn.net/xuejianxinokok/article/details/135742152

版权

java 专栏收录该内容

57 篇文章 3 订阅

订阅专栏

介绍

如果您的工作配置与 Java 有一定的关系，您一定已经注意到了Java 最新稳定版本 Java 21 引起了很多关注。

这个新版本引入了一些未来的功能，改进了之前引入/孵化的一些突破性功能，弃用了多余的功能，并删除了一些错误。它使 Java 更具竞争力和活力，与其他流行的编程语言保持同步。

现代软件应用程序及其使用模式需要非常高的效率、安全性、吞吐量和可扩展性。随着软件开发范式的发展以满足这些需求（和威胁），流行的语言也在不断发展，而 Java 自然也不甘落后。

如果您关心优化并保持软件最佳性能，并充分利用尖端技术，那么这篇文章适合您。即使您不打算进行任何升级，您也可能需要进行现实检查或盘点当前的软件堆栈。随着我们运行软件和业务的环境不断变化，新的要求和威胁不断涌现。提前计划、修改和纠正一些事情总是更好。

利用最新的功能和特性使我们保持竞争力、兼容性和灵活性。在本文中，我们讨论从 Java 8 到 Java 21 的迁移；以及 Spring Boot 2 到 Spring Boot3.2/Spring Framework 6.1 我们的讨论重点是 Java 21 和 Spring Boot 3.2。

Java 21 令人兴奋的新功能：

Java 21 旨在保持 Java 的竞争力，提高性能和安全性，并增强其功能和特性。一些显著特点是：

Lightweight Virtual threads -
轻量级虚拟线程 - Java 21 支持thread-per-request式编程，通过虚拟线程实现近乎最佳的硬件利用率。以前，每个新创建的线程都必须对应一个新操作系统线程，这限制了新线程的创建。但是现在，虚拟线程允许创建许多共享同一个操作系统线程的虚拟线程，缓解了 thread-per-request风格编程创建线程的负担。。
Structured Concurrency API -
结构化并发 API - 协调、编排和观察上述虚拟线程，以提供更可靠和可维护的并发代码。
Scoped Values -
作用域值-作用域值允许安全有效地在线程之间共享变量/数据值。因此，来自同一父级的线程可以在它们之间共享信息/上下文，从而无需传递方法参数即可达到相同的效果。作用域值被声明为最终的和静态的，并且仅在线程执行期间的有限时间内可用，明确定义了虚拟线程可以共享变量的范围和规则。
Vector API -
Vector API - Java21 中的另一个开创性功能，它是在 Java 16 中孵化的。Vector API 允许指定在支持的 CPU 上编译为向量指令的向量计算，从而提供计算速度的成倍提高。向量指令可以处理多条数据，例如256 位处理器上的 8 个浮点值或 16 个短值，只需 1 个 CPU 指令。
相反，标量计算需要重复 8 次循环才能完成。
Record Patterns
记录模式为了使 Java 更适合解释和分析大量不同的数据，Java 21 中引入了记录模式的概念。
记录模式可以处理嵌套对象图，确定记录的确切类型，然后获取记录中的组成数据。
Enhanced SWITCH statement -
增强的 SWITCH 语句 - Switch 语句现在可以匹配记录模式和正则表达式，然后对匹配项执行特定操作。与记录模式相结合以解构记录值以实现更好的数据查询，此功能可实现出色的数据导航和处理。
Sequenced collections
排序集合像List/Set这样的集合对象现在有一个定义的顺序，可以有第一个/最后一个/下一个/上一个元素，并且它们可以颠倒。 Java 21 提供了一组统一的操作来访问这个定义良好的顺序，从而为开发人员提供了更多的能力。
Generational ZGC -
分代 ZGC - 这是改进的垃圾收集器，可以在不需要时谨慎地释放内存，从而优化资源利用率和系统性能。
Foreign Function & Memory API
外部函数和内存 API 与 JVM 外部的代码和数据进行互操作，以防您认为其他语言可以更好地完成特定任务。
更多 - 还有更多这样的功能，包括未命名类和无人模式、字符串模板、密钥封装机制等，这些都增加了 Java 21 的强大功能和多功能性。

上述一些功能的灵感来自其他语言（如 Python、Go 和 Rust）中的优秀工件。其中一些是在考虑到计算的未来以及 Java 广泛使用的领域的情况下引入的。许多这些功能都备受期待，因为它们是经验丰富的 Java 开发人员所要求的。

采用和迁移到Java 21 可能具有里程碑意义。

了解当前Java8 和SpringBoot2 的局限性

Java 8 是 2011 年推出的长期支持（LTS）版本，当时提供了一些很酷的功能，例如 Lambda 函数、流 API、数据和时间 API、接口中的默认/静态函数以及 Nashorn JavaScript 引擎。

Java 8 允许您编写可读且可维护的代码，这些代码可以与软件堆栈的其他部分很好地交互。 Java8 是最后一个免费的 LTS 版本，这一事实进一步增加了 Java8 的受欢迎程度。

对 Java 8 的支持已于 2019 年结束，在 2030 年之前只有有限的选项可用于商业支持。Java 9 的许可证更改有点被误解，我们认为 Java 的后续更改对社区和语言都有好处。您应该考虑从 Java 8 升级，因为 Java 已经先进、成熟，并添加了许多有用的功能。

虽然 Spring Framework 的初始版本侧重于消除样板代码并通过提供基本基础设施和自动配置来简化开发，但 SpringBoot3.2/Spring Framework 6.1 向前迈出了几步，添加了反应式支持（Webflux 以及 MongoDB 和 Cassandra 等）。）、改进的Actuator、增强的性能以及更好的自动配置等。

Java 8 和 Spring Boot 2 都很好，可能是十年前最好的选择。

虽然 Spring Boot 2 提供了 Spring-Hibernate 平台的改进功能，但 Java 8 是一个添加了强大功能的路径定义版本。随着基于云的应用程序和移动应用程序的爆炸式增长，该堆栈有能力满足两者的需求。 Java 8 仍然受到一些开发人员的喜爱，但 Java 本身在 11、17 和 21 LTS 版本中经历了许多变化。

与各自的最新版本相比，Java 8 的一些限制和约束是：

Java 8 缺乏诸如大幅改进的垃圾收集器和内存/资源管理之类的功能。
用于安全和加密、外部内存访问、流和矢量计算等的高级 API。
现代数据类型，如记录、虚拟线程、序列集合等。
类、接口和包装的改进和增强
改进的类加载器、系统监视器和工具

Spring Boot 2/Spring Framework 4 或 5 缺乏以下功能：

Spring Framework 6 的特性和改进
更好的性能、可扩展性、安全性和资源利用率
Jakarta EE 的最新功能，如验证、事务和 JSON/XML 支持
更好的 Servlet 容器和 GraalVM 镜像
更好的可观察性、追踪性和Micrometer Metrics

总体而言，Java 8 与 Spring Boot 2 曾经是一个强大的组合，但随着过去十年计算的进步和期望的变化，它现在看起来有点过时。

为什么要费心迁移到 Java 21 和 Spring Boot 3.2 呢？ - 我们对 Java 8 很满意！

Java 21 的发展方向是未来主义和开创性的。 Java 21 正在跟上其生态系统中其他语言的变化，例如 GO/Rust/JavaScript(ECMAScript2022)/Python 等。我们在这些语言中看到的许多增强功能都支持/促进了人工智能和机器学习。更新、更好、更相关的工具正在被添加，以增强可观察性和测量。

此外，您的程序使用并与之共存的其他 API/软件/库/工具也在不断发展和进步。您可能不想因为使用过时或无效的软件堆栈而落后。迟早，围绕软件的需求和期望也可能会发生变化。考虑升级到 Java 21 和 Spring Boot 3 是明智的做法。这也可能意味着在性能、安全性、可维护性以及最重要的可观察性方面获得潜在的改进。

因此，我们进一步的讨论将集中于简化过渡以及如何迁移到它。

SpringBoot3.2 和 Spring Framework 6.1 提供以下显著特性：

SpringBoot3.2可以与Java 21一起在GraalVm上运行。

GraalVM
GraalVM 是一个令人着迷的 JDK 发行版，它提供 Java 程序的提前 (AOT) 编译，它会修剪代码中不必要的部分，并将您需要的内容编译为操作系统和特定于体系结构的本机代码，运行速度与运行速度一样快作为本机 C 代码！

编译后的代码加载速度快，占用的 RAM 少得多，并优化了其运行平台上的 CPU 周期使用。想象一下以极快的速度运行 Java 程序，就好像它是 GO 或 C 程序一样！

您只需将以下内容添加到您的 gradle 配置中：-

java {
  sourceCompatibility = '21'
}

graalvmNative {
  binaries {
    main {
     buildArgs.add('--enable-preview')
  } } 
}

如果运行 Java 21，Spring Boot 3.2 提供对虚拟线程（Project Loom）的内置支持，因此您可以通过升级获得轻量级并发构造的好处。您只需要设置一个属性： spring.threads.virtual.enabled=true; Spring Boot 3.2 将开始使用虚拟执行器。锦上添花的是，虚拟线程执行器可以为许多技术自动配置，例如 RabbitMQ 监听器/Kafka 监听器/Spring Data Redis 的 ClusterCommandExecutor/Apache Pulsar 等。
CRaC (Coordinated Restore at Checkpoint)
CRaC（检查点协调恢复）是 Java 中的一种机制，允许您在 JVM+程序运行时拍摄快照并保存映像。稍后，如果您的 Java 程序遇到问题，您可以将其恢复到此快照以达到“最后已知的稳定状态”，并进一步解决问题。如果您遇到启动缓慢或预热时间较长的情况，此图像也非常有用。因此，要利用上述有用的功能，您必须考虑使用 Java 21 升级到 Spring Boot 3.2。
以 RestClientCustomizer 和 RestClientAutoConfiguration 的形式支持 Spring Framework 的 RestClient。 RestClient通过RestTemplate的基础设施提供WebClient的流畅API，通过可配置的模板、消息转换器、请求工厂和拦截器等使HTTP编程变得容易。
Observability,
顾名思义，可观察性是仅通过测量系统的外部输出来测量系统内部状态的能力。
在 Spring 6.1/SpringBoot3.2 中，引入了一项名为 Spring Observability 的新举措，其中 Spring 框架本身跟踪其内部指标，如日志/跟踪/其他指标，提供来自框架本身的更快/更好的信息。
您现在可以使用 Micrometer 的 @Timed、@Counted、@ContinueSpan 等注释。

此外，还添加了 R2DBC 和 AspectJ 的可观察性，并改进了开放遥测的自动配置。

根据上述增强功能，使用我们的 Unlogged 插件可以为您的观察添加整体跟踪/可视化/主动干预/代码优化。您现在就可以尝试该插件。

基于 NamedParameterJdbcTemplate 的存在，添加了 JdbcClient 的自动配置。
SSL 改进 - 现在，只需将其 reload-on-update 属性设置为 true，即可在信任材料发生更改时自动重新加载 SSL 捆绑包。
您可以在here. 查看许多其他有用的功能和增强功能。

为迁移做准备

一种方法是逐步向上过渡到 Java 11，然后过渡到 Java 17，最后过渡到 Java 21。虽然很耗时，但这样可以更平滑地过渡。

第二种方式是从Java 8直接跳转到Java 21。

无论您采用哪种方法，以下都是您在规划过渡时应考虑的一些准备工作和关键问题。

Migration Analysis Reports Tool -
迁移分析报告工具 - Java 21 提供了一个很酷且有效的工具来分析您现有的应用程序，并提供详细的报告来帮助您规划迁移过程并制定策略。

该工具的分析粒度非常细，可以识别源代码中需要修改的行号，并突出显示强制和建议的更改！

迁移分析报告详细介绍了将应用程序从较旧的 JDK 版本迁移到所需的较新 JDK 版本所涉及的迁移工作和风险。

该工具确实可以帮助您量化和衡量迁移所需的工作量，提供所需操作/练习的清晰图片，并帮助您做出明智的决策。

还在为您的迁移而担忧吗？ …在这里查看这个工具：- Java Migration Analysis

‍

从 Java 17 开始，强制执行更严格的封装，阻止对私有/受保护（非公共）字段和方法的未经授权的反射，如果您的代码到目前为止使用许可反射，在编译代码时则需要添加“–add-exports”和“–add-opens”。

–add-exports 允许运行时/编译时访问封装的内部 API，而 --add-opens 允许反射到“外部”Java API。

如果您使用的是 javax.util.regex.Pattern 类，请记住 Java 8 之后它的行为略有不同。否定运算符“[”用大括号括起来。
因此， [^u-v[w-x]y-z] 现在不会匹配 w 和 x，因为该运算符现在也适用于嵌套类。
在 Java 8 之前，它会匹配 w 和 x（之前不适用于嵌套类），但不会匹配 u-v 和 y-z，因为它们不是嵌套的。
您可以查看官方文档以获取更多详细信息和细粒度示例，包括 && 和 || 等等。

规划迁移工作、使用上述工具和问题将使您的流程更加顺利，并推动您成功迁移。充分的准备将简化您的流程并使其富有成效。

迁移清单

以下是迁移的两个常规清单：

A. Java 8 升级到 Java 21

除了“准备迁移”部分中详细介绍的步骤之外，以下步骤可以作为迁移的清单：

如果您的代码依赖版本字符串格式来区分主要版本、次要版本、安全版本和补丁更新版本，那么您可能需要更新它。

新版本字符串的格式为：$FEATURE.$INTERIM.$UPDATE.$PATCH

Class loader changes -
类加载器更改 - 应用程序类加载器现在是一个内部类，它不再是 URLClassLoader 的实例。扩展类加载器已更名为平台类加载器。引导类加载器现在加载很少的类，因此使用 Xbootclasspath/a 部署的 Java 8 应用程序或创建以 null 作为父级的类加载器的 Java 8 应用程序可能需要更改。
AppleScript、一些特定于 Apple 的包（例如 com.apple.eawt 和 com.apple.eio）被 java.awt.Desktop 包中与平台无关的对应项替换。您无法编译使用它们的代码，但编译为旧版本的现有代码将继续运行，因为它们（旧包）仅可用于运行时。
您无法选择 JRE 版本，如果您在命令行上使用version选项或在 JAR 文件中找到 JRE-Version清单条目，您将收到错误消息。

已弃用：- 有关已弃用功能的完整列表，请参阅此链接

deprecated. 方法 javax.management.remote.JMXConnector.getMBeanServerConnection(Subject) 支持旧版主题委托功能，并且仅与其他已弃用的 API 结合使用，因此现已弃用。
Applet API 以及 AWT 包中的许多接口和类现已弃用。
用于解析 String 以获取 Byte/Double/Float 等的构造函数方法已被弃用，您必须使用静态替代方法。
用于挂起/恢复/停止线程的线程方法已被弃用，您可能需要编写简单地修改某些变量的代码来指示目标线程应该停止运行。

B. Spring Boot 2 升级到 Spring Boot 3.2

Spring Boot 3 至少需要 Java 17，我们将安装 Java21，因此应牢记以下问题。

由于 Java EE 已更改为 Jakarta EE，Spring Boot 3.0 的所有依赖项 API 也从 Java EE 迁移到了 Jakarta EE。一些主要依赖项/包名称需要更改为：- 例如
```
   *.javax.servlet.*     --> jakarta.servlet.* 
   *javax.persistence.*  --> jakarta.persistence.* 
   *javax.validation.*   --> jakarta.validation.*
```
Spring Boot 3 是一个重大升级，因此需要更改几个配置属性，我们可以在 pom.xml 中使用 spring-boot-properties-migrator。可以在这里找到。

这将处理大多数所需的依赖项更改和命名更改。不过，下面列出了一些需要提及的重要配置。

由于我们正在升级 Java 和 Spring，因此您还应该将第 3 方 jar 更新到最新版本，例如Hibernate 6.3、Hibernate Validator 8.0、Jackson 2.15、Jersey 2.41、SLF4J 2.0.6、Tomcat 10.1 等。
Micrometer 1.10 中引入的最新观察 API 和 Micrometer Tracing

a.) 由于新的 Spring Boot 版本不推荐使用配置尾部斜杠匹配的选项，因此如果您需要启用尾部斜杠匹配，请定义自己的配置类

  public class WebConfiguration implements WebMvcConfigurer {
   @Override
   public void configurePathMatch(PathMatchConfigurer configurer) {
    configurer.setUseTrailingSlashMatch(true);
   }
 }

属性 server.max.http.header.size 已弃用，取而代之的是 server.max-http-request-header-size，它现在仅检查请求标头大小。因此，您可能需要定义一个实现 WebServerFactoryCustomizer 接口的新 bean，以定义响应标头大小的限制。例如。

@Configuration
public class MyServerConfiguration implements WebServerFactoryCustomizer {
@Override
public void customize(TomcatServletWebServerFactory defFactory)
{
  defFactory.addConnectorCustomizers(new TomcatConnectorCustomizer() {
  @Override 
  public void customize(Connector myConnector) {                               
     connector.setProperty("maxHttpResponseHeaderSize", "200000");
  } });
}   
}

Spring Boot 3.0 使用 Spring Security 6.0。，因此您可能需要在此处添加细粒度的安全设置。
您还可以查看 Spring-Boot-3.0-Migration-Guide 和 Spring-Framework-6.0-Migration- Guide 了解细粒度的详细信息。

由于我们不知道您的应用程序实现的具体业务逻辑，也不知道其内部架构，因此我们建议至少阅读一次迁移指南。

Java 21 迁移的最佳实践和最终步骤

一旦 Java 21 能够正常工作，以下措施将有助于充分利用 Java 21：-

如果需要，可以使用 javac 工具中的新 --release 标志交叉编译到平台的旧版本。
使用静态分析工具 jdeprscan 来查明您是否仍在使用任何已弃用的 API
升级代码时值得考虑 IDE 的建议
想要使用最新 Apple Metal API 的 Mac OS 用户可以启用新的渲染管道 https://openjdk.java.net/jeps/382
添加我们的 IDE 插件的强大功能； Java 的开源记录和回放，包括断言、模拟和代码覆盖率；通过安装未登录。

结论

我们讨论了升级到 Java 21 的一些关键优势以及 Java 21 中的开创性功能。为了简化迁移过程，我们讨论了如何为迁移做好准备、使用专门为此目的制作的工具、清单和问题来简化迁移过程。意识到。此外，我们还建议升级到 Spring Boot 3.2，以及如何最好地进行 Spring Boot 2 到 Spring Boot 3.2/ Spring Framework 6 的迁移。

所有想要充分利用最新技术、保持应用程序灵活和可扩展、增强安全性和弹性并为未来增强做好充分准备的人；应该阅读这个博客。

Java 非常重视跟上现代语言和流行的使用模式，因此 Java 21 不仅具有开拓性，而且还将使您能够利用未来的创新。

谢谢你的阅读：）

原文:Migrating from Java 8/11 to Java 21, and Spring Boot 2 to the latest Spring Boot 3.2