本文针对Java模块化开发中，从Module返回对象类型转换失败的问题，提供了两种解决方案。第一种方案强调模块化的一致性，确保`Foo`类只被加载一次。第二种方案利用代理模式，在不同类加载器之间架起桥梁，实现对象方法的调用。同时，文章也指出了代理模式的潜在问题，并建议在设计时考虑使用`ServiceLoader`等更简洁的方案。
在Java 11及以上版本中，使用模块化系统（Jigsaw）可以更好地组织和管理代码。然而，在模块化环境中，由于类加载器的隔离性，可能会遇到类型转换的问题。本文将探讨如何解决从Module返回对象后进行类型转换失败的问题，并提供两种可行的解决方案。
问题描述
假设存在两个模块：Implementation和Model。Implementation模块依赖于Model模块，并提供一个方法，该方法返回一个Foo类型的对象，Foo类定义在Model模块中。在一个独立的应用程序中，通过ModuleLayer加载这两个模块，并调用Implementation模块中的方法。当尝试将返回的Object类型转换为Foo类型时，可能会遇到ClassCastException，即使Model模块的jar包位于classpath中。
立即学习“Java免费学习笔记（深入）”；
原因分析
出现ClassCastException的根本原因是Foo类被不同的类加载器加载了两次。位于classpath中的jar包会被视为未命名模块，由应用程序的类加载器加载。而通过ModuleLayer加载的Model模块则由另一个类加载器加载。因此，即使类名相同，但由于来自不同的类加载器，Java虚拟机认为它们是不同的类型，从而导致类型转换失败。
解决方案
以下提供两种解决方案，以解决在Java模块化环境中进行类型转换的问题：
方案一：模块化一致性
此方案的核心思想是确保Foo类只被加载一次，避免出现多个类加载器加载相同类的情况。
-
应用程序模块化： 将包含调用Implementation模块代码的应用程序也定义为一个模块，并声明对Model模块的依赖。
module App { requires Model; } -
避免重复加载： 避免通过ModuleFinder再次加载Model模块。可以通过以下两种方式实现：
- (a) 不将Model模块的jar包放置在ModuleFinder指定的路径下。
- (b) 调整Configuration.resolve()中ModuleFinder的顺序，优先使用应用程序模块路径中的Model模块。
Configuration cf = parent.configuration().resolve(ModuleFinder.of(), finder, Set.of("Implementation"));通过以上步骤，Implementation模块将使用应用程序模块路径中的Model模块，避免重复加载，从而解决类型转换问题。
方案二：使用代理模式
此方案适用于Foo是一个接口的情况。通过动态代理，可以在不同的类加载器之间架起桥梁，实现对Foo对象方法的调用。
-
创建代理方法： 创建一个proxyOf方法，该方法接收一个Object类型的参数（即从Module返回的对象），并返回一个Foo接口的代理对象。
private Foo proxyOf(Object result) { InvocationHandler handler = (proxy, method, args) -> { Method delegate = result.getClass().getMethod(method.getName(), method.getParameterTypes()); return delegate.invoke(result, args); }; return (Foo) Proxy.newProxyInstance(this.getClass().getClassLoader(), new Class[]{ Foo.class }, handler); } -
调用代理方法： 在获取到Object类型的返回值后，调用proxyOf方法将其转换为Foo接口的代理对象。
Object provider = method.invoke(null, "test"); Foo myProvider = proxyOf(provider);
注意事项
-
访问权限： 确保应用程序代码有权访问delegate方法。如果delegate方法或其所在的类不是public的，需要使用delegate.setAccessible(true)来绕过访问限制。如果应用程序位于一个模块中，则需要在module-info.java文件中使用opens子句开放相应的包。
module Implementation { requires transitive Model; exports org.example.impl; opens org.example.impl; } 代理模式的局限性： 代理模式在处理JRE自带的类型时效果良好。但是，当传递自定义类型时，method.getParameterTypes()可能会返回错误的类型，导致NoSuchMethodException。此外，如果需要传递自定义类型的代理对象，则情况会变得更加复杂。
总结与建议
本文介绍了两种解决Java模块化环境中类型转换失败问题的方法。模块化一致性方案通过确保类只被加载一次来避免类型转换错误，而代理模式则通过动态代理来实现跨类加载器的对象方法调用。
在实际开发中，应根据具体情况选择合适的解决方案。如果Foo是一个接口，并且只需要调用其方法，则代理模式可能是一个不错的选择。然而，如果需要传递自定义类型的参数或返回值，则代理模式可能会变得复杂。
此外，建议考虑使用ServiceLoader等更简洁的方案来实现模块间的交互。ServiceLoader可以自动发现和加载服务提供者，从而避免显式地加载类和进行类型转换。
最后，理解Java模块化系统的类加载机制是解决此类问题的关键。只有深入理解模块化系统的原理，才能更好地利用其优势，并避免潜在的问题。
