迁移到 java11 ClassCastException [重复]答案

【问题标题】：Migration to java11 ClassCastException [duplicate]迁移到 java11 ClassCastException [重复]
【发布时间】：2019-02-10 16:52:43
【问题描述】：

我有一个以前在我的 java 程序中使用的库。

它包含下一行：

URLClassLoader cl = (URLClassLoader) ClassLoader.getSystemClassLoader();

它在 java8 上运行正常，但是在我尝试在 java11 上启动它之后，我得到了 ClassCastException

java.lang.ClassCastException: 类 jdk.internal.loader.ClassLoaders$AppClassLoader 无法转换为类 java.net.URLClassLoader

是否可以在不修改库的情况下解决此问题？ AFAIK，Java 应该是向后兼容的，所以也许一些命令行参数可能会有所帮助？

谢谢

【问题讨论】：

这个变化是在 java-9 中引入的，并且从来没有官方规范说应用程序类加载器必须是 URLClassLoader 的实例，所以这里没有向后兼容性。如果您需要帮助，不妨解释一下您对生成的类加载器做了什么。
Java 9 带来了一些改变，使一些假设无效。这是这些假设之一。也许有一种解决方法，但库很可能需要更新。相关帖子：stackoverflow.com/questions/46694600/…
不幸的是，不是我的代码使用URLClassLoader，我不能直接修改它:(
嗯...我希望你已经通过一些接口正确地将外部库从你的核心应用程序中分离出来，现在可以切换到不同的实现或实现你自己的:)

【解决方案1】：

Java 是向后兼容的。查看ClassLoader.getSystemClassLoader() in Java 8 表明它返回ClassLoader-instance，而不是URLClassLoader-instance。 ClassLoader.getSystemClassLoader() in Java 11 也是如此。因此，永远无法保证ClassLoader.getSystemClassLoader() 返回URLClassLoader。

据我所知，没有办法将ClassLoader 转换为URLClassLoader。解决此问题的唯一正确方法是编写库的维护人员并告诉他们他们依赖于一些实现细节，他们不应该这样做并要求他们解决问题。如果修复起来很容易并且项目是开源的，您可以分叉项目、修复问题并创建拉取请求。

【讨论】：