我正在尝试访问com.sun.tools.javac.util
中的List
类。这在Java 8中可以正常工作,但切换到Java 9后,我会收到以下错误:包'com.sun.tools.javac.util'声明在模块"jdk.compiler"中,该模块未将其导出到未命名模块"
。
我尝试将requires jdk.compiler;
添加到我的module-info
文件中,但这并没有解决问题。
我正在尝试访问com.sun.tools.javac.util
中的List
类。这在Java 8中可以正常工作,但切换到Java 9后,我会收到以下错误:包'com.sun.tools.javac.util'声明在模块"jdk.compiler"中,该模块未将其导出到未命名模块"
。
我尝试将requires jdk.compiler;
添加到我的module-info
文件中,但这并没有解决问题。
从长远来看,处理这种情况的安全方法是不再使用 JDK 的这些内部 API。
可以使用 jdk.compiler
模块的 API 作为 com.sun.tools.javac
包的替代。
定义了 系统 Java 编译器 及其命令行等效物 javac 和 javah 的实现。
特别是对于 com.sun.tools.javac.util.List
,它的几乎所有未重写的自定义方法都可以基于接口 java.util.List
的实现得出。
迁移指南中的 已删除的 java.*
API 列中指出 -
Java 团队致力于向后兼容性。如果应用程序在 JDK 8 中运行,只要使用受支持且用于外部使用的 API,则它将在 JDK 9 上运行。
这些包括:
- JCP 标准、
java.*
、javax.*
- JDK 特定的 API,一些为
com.sun.*
,一些为jdk.*
支持的 API 可能会从 JDK 中删除,但只有在提前通知的情况下才能删除。 运行静态分析工具
jdeprscan
,以查找代码是否使用了已弃用的 API。
接着,为了加强上述风险..
JDK 9 封装的内部 API 在编译时不可访问,但可以通过 --add-exports
命令行选项使其在编译时可访问。
在你的情况中:
--add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
在运行时,如果它们在JDK 8中是可访问的,那么它们将始终可访问,但在将来的版本中,它们将变得不可访问,在此时可以使用--add-exports
或--add-opens
选项使其在运行时也可访问。
如果使用以下参数 gradle.settings,可能会有所帮助。
org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8
kotlin.code.style=official
javax.tools
。未导出包中的类不可用。 - M. le RutteArrayList
或标准工厂方法返回的专门列表之一。 - Holger