将Java 8项目迁移到Java 11

Question

我们有一个使用Java 8构建的代码库，其中包含多个REST服务。我们想要迁移到Java 11，正在尝试找出最佳方法。我们考虑逐个模块进行升级。例如，将一个服务从Java 8改为Java 11，而其他服务仍然是Java 8。我们不确定Maven是否支持这样的操作？

- Mfswiggs

---

我遇到了同样的问题。Maven支持所有迁移，除了部署部分。这是由于详细日志记录引起的。 - Swarit Agarwal

如果您有一个模块级别的pom，您可以在编译阶段控制特定模块的JAVA版本。 - Aman Saurav

请尽量提供在迁移过程中遇到的具体问题示例，这样可以更容易地根据每个案例进行回答。 - Spyros K

你可以尝试使用IBM的应用程序二进制迁移工具包 - https://developer.ibm.com/wasdev/docs/migration-toolkit-application-binaries-tech/，也许这会对你有所帮助。 - Woworks

你的测试覆盖率好吗？ - Freiheit

Java 8 到 9 是最大的跳跃。我建议逐步升级，而不是试图一次性跳过 3 个主要版本。Oracle 为每个版本发布迁移指南。对于任意数量的跳跃，没有这样的指南。 - Michael

Answer 1

声明：这不是一个答案，只是我最近经验的部分报告。如果您觉得它不符合SO标准，请随意标记此答案。

Maven支持这个吗？

是的，使用编译器插件3.8.0/3.8.1

但是，这种迁移需要额外的关注。

最近我们做了类似于从ORACLE JDK 8到OPENJDK 11的迁移。由于我们有数百个具有不同任务的存储库，我们遇到了各种问题。仅举几个我在这里通过电子邮件标记为[jdk11_migration]的问题：

• It is quite obvious but I'd like to highlight that in order to migrate from java 8 to 11 we have to meet the requirements from java 9 and 10 as well

• Some maven plugins like cobertura do not support Java 11 and I guess they will never support it. In some cases, these plugins have reached the abandoned life cycle stage. The solution was looking for alternatives in a case to case manner. For example, we replaced cobertura by Jacoco.

• rt.jar and tools.jar have been removed! Everything you have explicity refered from them will probably break.

• some classes which we shouldn't use in java 9 or less now in java 11 no longer exist. I'm talking about to access classes in packages like sun.*, sun.misc etc. The solution is to look for a one-to-one replacement or refactor the code to avoid the usage.

• Reflection usually is the last bullet to use and, for these cases, in java 9 and above we geta warning messages like:

  WARNING: An illegal reflective access operation has occurred
  WARNING: Illegal reflective access by ...
  WARNING: Please consider reporting this to the maintainers of ...
  WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
  WARNING: All illegal access operations will be denied in a future release
  

虽然它并不是一个完美的解决方案，但有一个标记可以消除这个警告——illegal-access=permit。当使用surefire maven插件时，这尤其重要。

• Java 9引入了模块化系统，因此我们现在有了包冲突的现象。例如，出现“包org.w3c.dom可从多个模块访问：, java.xml”的消息。解决方法是找到冗余包含的源头（特别是重复的maven依赖或依赖的依赖项）并删除它们。

虽然对我们来说这不是问题，但我注意到你的存储库主要由REST组件组成。可能你会遇到ClassNotFound问题，涉及到一些像javax.xml.bind这样的包，它们基本上已经从Java标准版中删除了。你可以通过在pom.xml中显式地包含它们来修复它们。

幸运的是，在你的迁移过程中，你可能会在SO或互联网上找到每个问题的好问题和答案。野外还有一些迁移指南，是很好的起点。特定问题，如混淆和IDE集成，可能需要花费一些时间，但至少根据我的经验，这次迁移比我想象的要容易。

- Duloren

Answer 2

我的建议是升级整个项目。尝试使一些Java8和一些Java11模块变得非常困难。正如您已经知道的那样，从Java9开始出现了模块。答案非常通用，因此很难给出详细的响应。我想：

- 您的项目是由Maven管理的 - 您有许多构件（jar） - 您正在使用某些库或框架（谁说了Spring？） - 您正在使用源代码版本控制（例如Git或Subversion） - 您有一个多模块项目 - 您编写的代码适用于Java8和Java11平台

我的建议计划：

1. 在您的SVC上为Java11项目版本创建一个分支并开始工作。 2. 为公共定义创建一个父模块 3. 升级Maven插件和所有库到最新版本。对于Maven编译器，设置Java11目标（只有最新版本的Maven编译器插件支持Java11）。 4. 对于每个模块，定义导出的包（并指定需要哪些包） 5. 如果有许多模块，请先从其中几个开始，然后再包含其余部分。

如果有帮助的话，可以看一下这个github上简单的项目（它针对Java11，是一个多模块Maven项目）。

希望能帮到你。

- xcesco