在java8中编译我的项目然后在java 17上运行它是否可行答案

【问题标题】：Is it viable to compile my project in java8 and then run it on java 17在java8中编译我的项目然后在java 17上运行它是否可行
【发布时间】：2021-11-01 05:07:51
【问题描述】：

我已经阅读了几篇文章，其中在 jdk 9 中删除了 .* API。删除是否意味着它们已完全从 jdk 9 中删除，或者它们被标记为已弃用？

鉴于上述陈述，如果项目是 jdk 8 编译的，它会在 jdk 17 上运行而没有任何问题吗？我是第一次尝试这个，但是由于模块化的变化，tomcat 无法支持 jdk 8。

我计划在 jdk 8 中编译，然后在 jdk 17 上运行，直到整个项目与 jdk 17 兼容（通过 jdk 17 兼容，我的意思是使用更新的 API，而不是使用现有的已弃用 jdk8 的 API）。

我的方向是否正确？还是我应该采用不同的迁移方法？

【问题讨论】：

不确定您所说的“直到整个项目都符合JDK 17”的意思;如果不是，那么你将如何在 JDK 17 上运行它？
@kaya3 符合 jdk 17，我的意思是使用更新的 API 而不是现有的弃用 API
为什么要“在 jdk 8 中编译，然后在 jdk 17 上运行”？如果您不使用 JDK 8 运行，那么使用它来编译代码是没有意义的。使用 JDK 17 编译会立即告诉您代码是否使用了移除 API（除非涉及反射），这比在运行时偶然发现要好得多。
“在 jdk 8 中编译，然后在 jdk 17 上运行”使得平滑过渡成为可能，因为不需要一次更新所有实例

标签： java java-8 openjdk-17

【解决方案1】：

删除是指它们已从 jdk 9 中完全删除，还是被标记为已弃用？

有些已被标记为已弃用。其他的已被完全删除。虽然一般不在 Java 9 中。大部分删除是在以后完成的，有些仍然会发生。如果您查看现在被注释为 @Deprecated 的元素，在某些情况下，该注释将正式表明该元素将被删除。

鉴于上述陈述，如果项目是 jdk 8 编译的，它会在 jdk 17 上运行而没有任何问题

不一定。发生的另一件事是对“内部”Java SE API 的访问已逐渐关闭。因此，如果您的应用程序使用这些 API，在 Java 9 中您会收到警告，在 Java 11 中默认情况下会出现错误，而在 Java 17 中，某些访问（我认为）变得不可能。

所以...可能存在“问题”。

迁移的正确方法就是这样做。测试，测试，测试，直到你解决所有问题。

显然，这意味着您需要测试服务器，并且您需要使用带有单元测试、功能测试、UI 测试等的自动化测试框架。但这些只是很好的软件工程实践。你应该已经关注他们了。

我计划在 jdk 8 中编译，然后在 jdk 17 上运行，直到整个项目与 jdk 17 兼容（通过 jdk 17 兼容，我的意思是使用更新的 API，而不是使用现有的已弃用 jdk8 的 API）。

我的方向是否正确？还是我应该采用不同的迁移方法？

没有。正如@Holger 指出的那样，由于Java 17 编译器会识别出的问题，您可能会遇到很多运行时错误。

只有一种方法……真的。在 Java 17 上编译，直到确定所有编译时依赖问题；即使用已被删除或关闭的 API。然后在 Java 17 上运行并测试、测试和测试，直到发现所有其他问题。

在开始之前，建议检查项目的所有依赖项（库等），看看它们是否在 Java 17 上支持。然后将它们更新为正确的（可能是最新的）版本。

Java 17 仅发布了几周，因此很有可能您的一些依赖项还没有跟上。如果是这样的话，在这个阶段以 Java 11 LTS 为目标可能是一个更好的主意。

【讨论】：