好程序员Java培训分享：Java17你用上了吗？Spring Framework 6 将采用 Java 17 和 Jakarta EE 9。

正如在 SpringOne 上宣布的那样，Spring Framework 6 和Spring Boot 3 计划在 2022 年第四季度实现总体可用性的高端基线：

Java 17+(来自 Spring Framework 5.3.x 线中的 Java 8-17)

Jakarta EE 9+（来自Spring框架5.3.x 线中的 Java EE 7-8）

这一前瞻性的基线将为我们的 APl 设计和集成工作带来巨大的好处，在未来的许多年里，它将为应用程序代码和框架以及应用程序带来光明。然而，这当然是有代价的：Spring Framework 6 和 Spring Boot 3 的应用程序在运行时至少需要 JDK 17，以及 Tomcat 10 /Jetty 11（为了兼容 Jakarta EE 9）。更重要的是，在你的应用程序源代码中可能需要一些更改：例如在 jakarta EE 9 中 javax 到 jakarta 命名空间的更改，无论你在哪里接触 Servlet API、JPA、Bean Validation 等。

虽然一开始这听起来有点咄咄逼人，但请记住，我们谈论的是2022年第四季度的发布：届时，不仅 JDK 17 将取代 JDK 11 成为下一个长期支持版本，而且它本身也将被 JDK 18 和 JDK 19 作为当时可用的特性版本取代，而 JDK 20 的特性已经接近冻结。

Jakarta EB 9 也一样：我们预计届时 Jakarta EE 10 将会推出，而另一代 Tomcat、Jetty 和 co 将作为运行时选项被支持。保持以上基线作为最小值，这允许在 Spring Framework 6.x 中进一步了解 Java 的发展，Java 17 和 Jakarta EE 9 只是开始。

同时，Spring Framework 5.3.x 和 Spring Boot 2.x 目前仍在积极开发中，今年 11 月将推出 Spring Boot 2.6，然后在 2022 年 5 月推出 Spring Boot 2.7，最近一次 Spring Boot 2.x 特性分支已经到达（还没有确定这是 2.7 还是可能的更高版本），该分支将与 Spring Framework 5.3 一起进入扩展的开源维护阶段。与 Spring Framework 6 和 Spring Boot 3 并行，有好几年的重叠。考虑我们之前对 Spring Framework 3.2.x 和4.3.x 的分支，以了解在实践中将如何实现。

因此，如果你打算继续使用 JDK 8 或 11 几年，或者即使你打算继续使用 JDK17上的 Spring Framework 5.3 基础设施几年，请放心，我们对 Spring Framework 5.3.x 和 Spring Boot 2.x 的扩展维护是可以的，会让你覆盖。

一旦你准备使用下一代应用程序的 Java 生态系统，以自己的节奏随时升级到 Spring 框架 6 和 Spring Boot 3，随着 Tomcat、Jetty 和 co——新基础设施的好处和新建筑成为可用的选项。我们希望在接下来的几年里你们会欣赏这些选择。

为什么要升级到 Java 17？

Java 17, Java 语言和运行平台的下一个长期支持（LTS）版本，将于 9 月 14 日正式发布。不幸的是，许多应用程序仍然在旧版本的 Java 上运行，比如以前的 LTS 版本：Java 11 和 Java 8。本文解释了为什么应该升级应用程序，并帮助您实际升级到Java 17。

好程序员Java培训分享：Java17你用上了吗？但首先，你们很多人可能会问：“为什么升级？”

为什么会有人想要升级到最近的 Java 版本？特别是如果你的应用程序在 Java 8、Java 11、Java 14 或您正在使用的任何版本上运行得很好时，这是有理由怀疑的。升级到 Java 17 需要付出努力，尤其是对那些目标是真正利用 JVM 中的新语言特性和功能的人。

没错，根据环境和应用程序的不同，可能需要进行一些升级。开发人员和其他团队成员需要更新他们的本地环境。此外，构建环境和运行环境（如生产环境）也需要升级。

幸运的是，许多项目和团队使用 Docker，它在这方面帮助很大。在我自己的团队中，团队定义了他们自己的持续集成/持续部署（CI/CD）管道，他们用 Docker 映像运行一切。团队可以通过在他们的 Docker 映像中指定该版本升级到最近的 Java 版本——这不会影响其他可能在旧 Java 版本上运行的团队，因为这些团队使用的是旧的 Docker 映像。

在 Kubernetes 上运行的测试和生产环境也是如此。当一个团队想要升级到一个新的 Java 版本时，他们可以自己更改 Docker 映像，然后部署所有内容。（当然，如果您仍然有共享的构建环境，或者其他管理您环境的团队，这个过程可能会有点挑战性。）

应用程序也可能需要做一些更改。我注意到，团队发现有这么多的工作量是很有挑战性的，以致将一个应用程序从 Java 8 升级到 Java 11 需要几周甚至几个月的时间。过高的估计往往会导致公司因为其他优先事项而推迟升级。

我试图升级了一个应用程序，估计需要几周时间，但实际只花了几天时间，主要是因为等待构建的完成。这部分是由于多年的升级经验，但这也是一个刚刚起步的问题，并试图在过程中解决问题。这是一个周五下午的好工作内容；看看你已经完成了多少工作，还有哪些挑战，这样就更容易估算剩下的工作。

然而，即使有多年的经验，在没有关于项目深入信息的情况下，我也无法估计升级需要多长时间。这很大程度上取决于应用程序有多少依赖项。通常，将依赖项升级到最近版本可以解决 Java 升级过程中可能出现的许多问题。

LTS 版本

本文一直引用 Java 8、Java 11 和 Java 17 作为 LTS 版本。这是什么意思？下面是对 Oracle Java SE 支持路线图的引用：对于 Java SE 8 之后的产品版本，Oracle 将每三年指定一个版本作为长期支持的（LTS）版本。Java SE 11 是一个 LTS 版本。出于 Oracle Premier Support 的目的，非 LTS 版本被认为是最近 LTS 版本的累积实现增强集。一旦一个新的特性版本可用，任何以前的非 LTS 版本都将被认为是可取代的。例如，Java SE 9 是一个非 LTS 版本，并立即被 Java SE 10 （也是非 LTS ）所取代，而 Java SE 10 又立即被 Java SE 11 所取代。然而，Java SE 11 是一个 LTS 版本，因此，即使 Java SE 12 已经发布，Oracle 客户也将收到 Oracle Premier 支持和定期更新的版本。

在 Java 升级期间需要更改什么?

你的应用程序包含你和你的团队编写的代码，它可能还包含依赖项。如果从 JDK 中删除了某些内容，可能会破坏代码、依赖关系，或者两者都破坏。这通常有助于确保这些依赖项是最近的，以解决这些问题。有时，在开始升级过程之前，你可能必须等待框架发布与最近 Java 版本兼容的新版本。这意味着，作为升级前评估过程的一部分，您对依赖项要有很好的了解。大多数功能不会一下子从 JDK 中全部删除。首先，功能被标记为弃用。例如，用于 XML 绑定的 Java 体系结构（JAXB）在 Java 9 中被标记为弃用，然后在Java 11 中被删除。如果您不断更新，则会看到被弃用的部分，并且可以在功能被删除前解决这些特性的任何使用问题。但是，如果直接从 Java 8 跳到 Java 17，那么这个特性的删除将会立刻给您造成影响。要查看 API 的变化，例如，查看在特定的 Java 版本中哪些方法被删除或添加到 String APl 中，可以查看 Marc Hoffmann 和 Cay Horstmann 的 Java 版本年鉴，或者 Foojay 的 Java 版本年鉴。

结论

升级依赖关系并为已删除的 JDK 特性添加依赖关系可以解决许多 Java 升级挑战。我建议采用一种结构化的方法逐步升级：首先，确保代码已编译，然后运行测试，再运行应用程序。

如果你告诉自己、团队和公司你可以在 JDK 17 上编译和测试所有的东西，而不是告诉他们它几乎已经完成了，或者更糟的是，它只完成了 80%，那么迁移的过程就会容易很多。

从 JDK 11 升级到 JDK 17 要比从 JDK 8 升级到 JDK 11 容易得多。然而，在这两种情况下，对于重要的应用程序来说都是几个小时到几天的时间不等，这主要是由于等待构建完成。好程序员Java培训分享：Java17你用上了吗？