java - 从 Java 7 迁移到 12 时如何找到替换包？

Question

我正在将一个巨大的整体应用程序从 java 1.7 迁移到 12，我希望以正确的方式完成它，并尽可能减少修改。我理所当然地经常遇到这样的错误:

[ERROR] /home/idiot/projects/projects/blah/blah/src/blah/blah/blah/Blah.java:[8,18] package sun.nio.cs.ext is not visible

和

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project blah: Compilation failure
    [ERROR] /home/idiot/projects/blah/blah/src/blah/blah/blah/Bblah.java:[152,42] package com.sun.org.apache.xerces.internal.dom is not visible
    [ERROR]   (package com.sun.org.apache.xerces.internal.dom is declared in module java.xml, which does not export it)

以及诸如此类的警告

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.python.google.common.base.internal.Finalizer (file:/home/idiot/.m2/repository/own/plugin/own-plugin-1.jar) to field java.lang.Thread.inheritableThreadLocals
WARNING: Please consider reporting this to the maintainers of org.python.google.common.base.internal.Finalizer
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

即使没有适当的教程来查找，模块化这个庞然大物的网络应用程序似乎也是不可能的。大多数 google 和 stack 结果都是适用于 java 11 之前环境的解决方案。大多数 google-fu 建议使用正确的包，而不是现在隐藏/过时的包。

挑战和我的问题是，如何找出现在过时的 API 被什么取代了？

有成百上千个文件使用反射、com.sun.org、sun.misc 包，一旦找出了查找替换包的步骤，如何去解决这个问题吗？只需手动浏览数千个文件并更新？

Answer 1

据我所知，没有一个来源列出了所有现有的替换包(尽管有一个就很好了)。相反，您需要为每个单独的问题寻找替代方案 - 如果不成功，我建议为每个包/用例创建一个新问题。

请注意，每个内部 API 很可能都没有官方替代品。恰恰相反，一般来说，大多数内部人员不会有公开的替代方案。许多人并不需要它，但我们总是会遇到一些 JDK API 根本不支持的边缘情况。在这种情况下(在找到解决方案之前，可以作为其他人的创可贴)，您可以使用 --add-exports 强制编译器和运行时导出/打开内部 API。和 --add-opens ，例如:

# your first compile error example
javac --add-exports jdk.charsets/sun.nio.cs.ext=ALL-UNNAMED ...
java --add-exports jdk.charsets/sun.nio.cs.ext=ALL-UNNAMED ...
# your second compiler error example
javac --add-exports java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED ...
java --add-exports java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED ...
# your run-time warning example
java --add-opens java.base/java-lang=ALL-UNNAMED

以下是如何将 Maven 中的这些添加到编译器插件和 Surefire/Failsafe(相同语法):

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <!-- PLEASE ADD A COMMENT EXPLAINING WHICH CLASSES/DEPENDENCIES
                USE THIS INTERNAL API AND WHY! -->
        <compilerArgs>
            --add-exports jdk.charsets/sun.nio.cs.ext=ALL-UNNAMED
            --add-exports java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED       </compilerArgs>
    </configuration>
</plugin>
<plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <!-- PLEASE ADD A COMMENT EXPLAINING WHICH CLASSES/DEPENDENCIES
                USE THIS INTERNAL API AND WHY! -->
        <argLine>
            --illegal-access=deny
            --add-exports jdk.charsets/sun.nio.cs.ext=ALL-UNNAMED
            --add-exports java.xml/com.sun.org.apache.xerces.internal.dom=ALL-UNNAMED
            --add-opens java.base/java-lang=ALL-UNNAMED
        </argLine>
    </configuration>
</plugin>

( Explanation of --illegal-access 以及为什么应该添加它。)

是的，这些都是“肮脏的解决方法”，但它们比 Java-9 之前的方式有一个优势:您对内部 API 的依赖现在是明确的，并且到处添加命令行标志的不便会让您有动力停止这样做它。 😉

There are hundreds and thousands of files using reflections, com.sun.org, sun.misc packages, once the steps to find the replacement packages is figured, how to go about addressing this? Just manually go through thousands of files and update ?

是的。就好像使用它们一开始就是一个坏主意。