已弃用的认可标准覆盖机制和扩展机制的替代方案答案

【问题标题】：Alternative for deprecated endorsed-standards override mechanism and extension mechanism已弃用的认可标准覆盖机制和扩展机制的替代方案
【发布时间】：2015-03-11 10:20:08
【问题描述】：

release notes for Java 8 Update 40 (8u40) 状态：

认可的标准覆盖机制和扩展机制已弃用，可能会在将来的版本中删除。没有运行时变化。使用“认可标准”的现有应用程序建议迁移“覆盖”或“扩展”机制避免使用这些机制。

还有一个问题澄清了 Jigsaw（计划用于 Java SE 9，AFAIK）将以某种方式被模块化方法取代：

http://bugs.java.com/view_bug.do?bug_id=8065675

我了解 Oracle 现在想要弃用这些机制，因为它们在 Java SE 9 中不再支持它们。

另一方面，在不提供替代方案的情况下弃用某些东西并不是一个好习惯。

发行说明指出：“现有应用程序 [...] 建议不要使用这些机制”

那么你怎么能“迁移离开”

认可的标准覆盖机制
扩展机制

在 Java SE 8 中？

【问题讨论】：

哪里说 Java 9 不支持？
@EJB 这就是我的理解。例如。在问题中：“展望未来，我们希望通过可升级模块 [2] 的概念仅以模块化形式支持认可的标准和独立 API。”也许我也在其他资源中读到了一些关于此的内容。 AFAIK Jigsaw 计划用于 Java SE 9。但同样，这至少是我目前的理解，不一定是事实。您还有其他相关信息吗？
'Going forward' != Java 9. 你过度恐慌了。他们没有提到目标版本或时间表。我认为你是安全的，直到至少一个主要版本通过同时存在两种机制：可能是两个或更多。
@EJP，也许你是对的。不过，有没有办法像 8u40 发行说明中建议的那样“迁移”，这样我们就可以为新情况做好准备并避免使用已弃用的功能？还是只有 Jigsaw 才能做到这一点（但此时该建议至少令人困惑）？
@EJP 一些背景信息：这不仅是一个理论问题，而且我目前处于一种情况，我认为我必须在我正在编写的框架中使用一个认可的库。阅读这些发行说明，我意识到我将使用一些已经被弃用的东西。所以我的问题是：当时有更好的方法吗？相关问题是：stackoverflow.com/questions/26769891/…

标签： java java-8 java-9

【解决方案1】：

我找到了以下文章，其中解释了这些机制确实计划在 Java SE 9 中删除：

https://blogs.oracle.com/java-platform-group/entry/planning_safe_removal_of_under

不幸的是，您现在似乎无能为力，例如对于属于 JRE 的库。

如果您受到影响该怎么办

虽然大多数应用程序不使用认可的标准或扩展机制，一些应用程序这样做。如果您是开发人员，请考虑提供依赖项作为一部分您的应用程序，而不是需要外部系统配置。如果您不是开发者，请联系个别软件供应商寻求支持。

【讨论】：

【解决方案2】：

使用 Java 8，您可以继续使用已弃用的机制。 Oracle 仅提供一种方法来检查您的应用程序是否利用 Java 8 更新 40 及更高版本中提供的 java.exe 标志 -XX:+CheckEndorsedAndExtDirs [1] 机制。

当你升级到 Java 9 时，为了避免你的 Java 应用程序在运行时失败，出现由 ClassNotFoundException 引起的 NoClassDefFoundError 之类的

Exception in thread "pool-1-thread-3" java.lang.NoClassDefFoundError: javax/rmi/CORBA/Stub
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
        at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown Source)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(Unknown Source)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        at org.jacorb.orb.ORB._getDelegate(ORB.java:541)
        at org.jacorb.orb.ORB.string_to_object(ORB.java:2110)
--snip--
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: javax.rmi.CORBA.Stub
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        ... 26 more

您需要使用以下参数更新您的 java.exe 启动命令行 --添加模块 --补丁模块 -添加出口

有关具体示例，请参阅 Grzegorz Grzybek 于 2016 年 9 月在 jacorb-developer 邮件 [2] 上发表的帖子。我们必须使用 Java 9 的附加命令行参数来更新应用程序的 Windows 批处理文件，例如

java --add-modules "java.corba" --patch-module "java.corba=..\lib\jacorb-omgapi-3.4.jar" --add-exports=java.corba/org.omg.CONV_FRAME=ALL-UNNAMED --add-exports=java.corba/org.omg.CORBA_2_5=ALL-UNNAMED --add-exports=java.corba/org.omg.PortableGroup=ALL-UNNAMED --add-exports=java.corba/org.omg.ETF=ALL-UNNAMED --add-exports=java.corba/org.omg.GIOP=ALL-UNNAMED --add-exports=java.corba/org.omg.SSLIOP=ALL-UNNAMED --add-exports=java.corba/org.omg.CSIIOP=ALL-UNNAMED -jar ourapp.jar

一个与 CORBA 和 Java 相关的脚注，CORBA（和 JAXB）计划在 Java 11 中完全删除。请参阅“JEP 320：删除 Java EE 和 CORBA 模块”[3] 和这篇博文 [@987654324 @]。

【讨论】：

【解决方案3】：

您现在的回退是在执行 java 实例时显式列出您的类路径目录和 jar 文件。

【讨论】：

“正常”类路径不能替换 JRE、AFAIK 提供的类。
JRE 提供的是默认值。扩展已由用户从外部添加到 JRE 路径，通常被认为是一种反模式。我从来没有使用过 endorsed-dirs 功能。所有外部依赖项最好都列在类路径中。您在扩展中拥有的任何东西都应该以 .jar 或类目录的形式提供，也在类路径中。无论如何，这就是我的看法。