在分离的Java平台模块中使用依赖关系的不同版本 [英] Using different versions of dependencies in separated Java platform modules
问题描述
我希望可以在myModuleA中使用Guava-19，在myModuleB中使用guava-20，因为拼图模块具有自己的类路径.
I expected it's possible to use i.e. Guava-19 in myModuleA and guava-20 in myModuleB, since jigsaw modules have their own classpath.
假设myModuleA使用Iterators.emptyIterator(); -已在guava-20中删除，并且myModuleB使用新的静态方法FluentIterable.of(); -番石榴19中没有.不幸的是，我的测试是否定的.在编译时，看起来不错.与运行时相比，结果是NoSuchMethodError.意味着，类加载器上的第一个类决定哪个失败.
Let's say myModuleA uses Iterators.emptyIterator(); - which is removed in guava-20 and myModuleB uses the new static method FluentIterable.of(); - which wasn't available in guava-19. Unfortunately, my test is negative. At compile-time, it looks fine. In contrast to runtime the result is a NoSuchMethodError. Means that, the class which was the first on the classloader decides which one fails.
与底层耦合的封装?我找到了自己的理由.由于传递依赖项将具有与以前相同的问题，因此无法支持.如果模块A和模块B中的签名中发生了具有版本冲突的番石榴类，则取决于它.应该使用哪个类?
The encapsulation with the underlying coupling? I found a reason for myself. It couldn't be supported because of transitive dependencies would have the same problem as before. If a guava class which has version conflicts occurred in the signature in ModuleA and ModuleB depends on it. Which class should be used?
但是，为什么在Internet上我们都可以读到拼图-模块系统停止了类路径地狱"?现在，我们有多个较小的相似类路径"具有相同的问题.比问题更不确定.
But why all over the internet we can read "jigsaw - the module system stops the classpath hell"? We have now multiple smaller "similar-to-classpaths" with the same problems. It's more an uncertainty than a question.
推荐答案
版本冲突
首先进行更正:您说模块具有自己的类路径，这是不正确的.应用程序的类路径保持不变.与此平行的是引入了模块路径，但是它基本上以相同的方式工作.特别是，所有应用程序类均由同一类加载器加载(至少默认情况下).
Version Conflicts
First a correction: You say that modules have their own class path, which is not correct. The application's class path remains as it is. Parallel to it the module path was introduced but it essentially works in the same way. Particularly, all application classes are loaded by the same class loader (by default at least).
所有应用程序类都只有一个类加载器，这也解释了为什么同一类不能有两个版本:整个类加载基础结构是基于一个完全限定的类名足以标识一个类的假设而构建的.带有类加载器的类.
That there is only a single class loader for all application classes also explains why there can't be two versions of the same class: The entire class loading infrastructure is built on the assumption that a fully qualified class name suffices to identify a class with a class loader.
这也为多个版本的解决方案打开了路径.像之前一样，您可以通过使用不同的类加载器来实现这一点.模块系统执行此操作的本机方法是创建其他图层 (每个层都有自己的加载程序).
This also opens the path to the solution for multiple versions. Like before you can achieve that by using different class loaders. The module system native way to do that would be to create additional layers (each layer has its own loader).
模块系统是否也将类路径地狱替换为模块地狱?好吧，如果不创建新的类加载器，仍然无法使用同一库的多个版本，因此，这个基本问题仍然存在.
So does the module system replace class path hell with module hell? Well, multiple versions of the same library are still not possible without creating new class loaders, so this fundamental problem remains.
On the other hand, now you at least get an error at compile or launch due to split packages. This prevents the program from subtly misbehaving, which is not that bad, either.
这篇关于在分离的Java平台模块中使用依赖关系的不同版本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
