如何解决将 Java 8 代码迁移到 Java 11 的依赖性和包问题 [英] How to solve dependency and package issues migrating Java 8 code to Java 11

问题描述

我正在准备将我团队的整个项目组合迁移到 Java 11.所有应用程序均基于内部多年来开发的框架，其中某些部分已使用 12 年以上.

I am preparing the migration to Java 11 of the entire project portfolio of my team. All applications are based upon a framework that has been developed in-house over the years, with some parts being over 12 years old.

我遵循了这篇文章(和这个网页来自Oracle——它根本没有帮助)，使用 versions-maven-plugin-version 将所有依赖项更新到最新的 GA 版本.

I have followed the recommendations in this post (and this web page from Oracle – it did not help at all), using versions-maven-plugin-version to update all dependencies to their latest GA versions.

机器上只安装了一个JDK(11.0.4)并且Eclipse配置为源级别1.8、目标11和版本11.我还没有考虑在运行时环境中从1.8过渡到11的问题:暂时，我只是想整理一下编译问题.

There's only one JDK installed on the machine (11.0.4) and Eclipse is configured for source level 1.8, target 11 and release 11. I am not yet considering the problem of transitioning from 1.8 to 11 in runtime environments: for now, I just want to sort out compilation issues.

我目前有两个问题:

1. 错误:包 com.sun.rowset 不可见.(包 com.sun.rowset 在模块 java.sql.rowset 中声明，它不导出它)"
2. 可以从多个模块访问 org.w3c.dom 包:<unnamed>, java.xml"

问题 1

注意:此问题已解决，请参阅本文底部的编辑部分.

Problem 1

NOTE: This problem is solved, see EDIT section at the bottom of this post.

第一个问题源于这样一个事实，即过去有人有一个绝妙的主意使用类 com.sun.rowset.CachedRowSetImpl 这不是 API(并且可能不是在他们开始时使用它).

The first problem stems from the fact that someone in the past had the brilliant idea to use class com.sun.rowset.CachedRowSetImpl which is not API (and which probably wasn't when they started using it).

我所做的，使用其他问题和给出的答案作为基础，是用这个配置Maven:

What I have done, using other questions and the given answers as a basis, was to configure Maven with this:

<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<maven.compiler.release>11</maven.compiler.release>

我可能在这里摸不着头脑，但无论是在 Eclipse 中还是在命令行中，该配置都没有效果.我将围绕该错误用法添加测试，以便我可以用另一个实际上是 API 的类替换该类.

I'm probably poking in the dark here, but that configuration had no effect, whether in Eclipse or on the command line. I'll add tests around that incorrect usage so that I can replace the class with another one that is actually API.

第二个问题对我来说更重要.我们使用了许多包，主要用于 XML 处理，会产生该错误.以下是其中一些软件包:

The second problem is more crucial to me. We use many packages, mainly for XML processing, that generate that error. Here are some of these packages:

org.w3c.dom.Attr
org.w3c.dom.Document
org.w3c.dom.Element
org.w3c.dom.Node
org.w3c.dom.NodeList
org.xml.sax.SAXException
javax.xml.parsers.DocumentBuilder
javax.xml.parsers.DocumentBuilderFactory
javax.xml.parsers.ParserConfigurationException
javax.xml.transform.OutputKeys
javax.xml.transform.Result
javax.xml.transform.Source
javax.xml.transform.Transformer
javax.xml.transform.TransformerException
javax.xml.transform.TransformerFactory
javax.xml.transform.dom.DOMSource
javax.xml.transform.stream.StreamResult
javax.xml.transform.stream.StreamSource
javax.xml.validation.Schema
javax.xml.validation.SchemaFactory
javax.xml.validation.Validator

一种解决方案是从 Maven 依赖项中删除提供匹配包的工件.不幸的是，这样做会在其他地方产生错误，因为删除依赖项会使其他一些包不可用.例如，如果我将 xml-apis 留在依赖项中，则会出现包 x 可从多个模块访问"错误.如果我从所有将其作为传递依赖项拉取的依赖项中排除它，我会收到xxx 无法解析为类型"错误.

One solution is to remove the artifacts that provide the matching packages from the Maven dependencies. Unfortunately, doing so create errors elsewhere, in that the removal of the dependencies makes some other packages unavailable. For instance, if I leave xml-apis among the dependencies, I have the "package x is accessible from more than one module" error. If I exclude it from all dependencies that pull it as a transitive dependency, I get a "xxx cannot be resolved to a type" error.

依赖排除可能是一种解决方案，但基于该框架的投资组合是广泛的，排除意味着寻找可能存在的数百个可能存在相关依赖作为传递依赖的位置.

Dependency exclusion could be a solution but the portfolio resting on that framework is extensive and the exclusion would mean hunting down potentially hundreds of locations where incriminated dependencies could exist as transitive dependencies.

我的问题是关于如何继续解决问题 #2.

My question is about how to proceed to solve problem #2.

目前，我已将源代码和目标级别指定为 1.8，这不是一个可行的选项，但它是我迄今为止发现的唯一允许编译在 JDK 11 上成功的选项.

For the time being, I have resorted to specifying source and target levels of 1.8, which isn't a viable option but it's the only option I've found so far that allows the compilation to succeed on JDK 11.

由于 this answer另一个问题，问题 1 已解决.

Problem 1 is solved thanks to this answer to another question.

推荐答案

我今天遇到了问题 2.

I hit my head on the problem 2 today.

就我而言，避免导入就足够了

In my case, it was enough to avoid importing

<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>

这个工件/jar 包含相同的(与 XML 相关的)类，这些类与 Java 11 库冲突.这是因为我们收到错误包 x 可从多个模块访问".

This artifact/jar includes the same (XML related) classes, which clash with the Java 11 lib. This is because we get the error "package x is accessible from more than one module".

就我而言，我没有做任何其他事情.

In my case I did not do had to do anything more.

在您的情况下，(xxx 无法解析为类型")我猜您需要确保在编译时导入模块 java.xml .

In your case,("xxx cannot be resolved to a type") I'd guess you need to ensure to import the module java.xml , when compiling.

此页面建议

这可以通过在项目文件夹中创建一个文件 .mvn/jvm.config 并将选项放在那里来实现.这是一个简单的例子:

This is possible by creating a file .mvn/jvm.config in the project's folder and putting the options in there. Here's a simple example:

--add-modules java.xml.bind
--add-opens java.base/java.lang=ALL-UNNAMED
--illegal-access=deny

--add-modules 是在 Java 中包含模块的 javac 选项.

--add-modules is the javac option to include modules in Java.

这篇关于如何解决将 Java 8 代码迁移到 Java 11 的依赖性和包问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！