4 ms·

One thing I did not understand is why looking for class name collisions depends on modules. If I have two classes named com.foo.Bar in two different JARs, and I

by moring 5y ago

One thing I did not understand is why looking for class name collisions depends on modules. If I have two classes named com.foo.Bar in two different JARs, and I use both JARs (without any class loader trickery), then what part of the module system is needed to recognize this fact and throw an exception in my face? This seems interesting to me because most of the time, dependency management happens to include two versions of the same library by accident and a simple exclusion rule fixes the problem, but obviously only if you know about it in the first place.

Renevith 5y ago
It doesn't depend on modules. And in fact, you don't even have to wait until runtime and throw an exception: plugins like https://github.com/basepom/duplicate-finder-maven-plugin/wiki https://github.com/basepom/duplicate-finder-maven-plugin/wik... can enforce this at build time, with neat features like allowing two classes with the same name as long as their contents are 100% identical, or allowing specific exceptions where you can confirm they aren't going to cause problems. We run this plugin where I work. We have no plans to modularize our build since the duplicate class protection would just be worse that this plugin.
tsimionescu 5y ago
This is an implementation problem. For performance reasons, the JVM doesn't scan the entire classpath - when a Class object has to be created (to access one of it's members for the first time, such as a constructor or static method), some class loader is asked to scan the classpath until it finds that class (.class file, in .jar or directly on disk). This stops after the first successful find. This is also a reason why you can't use regular Java reflection to do something like finding all references to a method, or even finding all classes - classes are loaded on the fly, only as needed (there are libraries that modify this behavior, though).
gunnarmorling 5y ago
If these JARs are on the module path, this problem would be spotted at compile time, resulting in a failure due to the "split package" situation which has been created by having that class in more than one JAR.

by moring 5y ago

Renevith 5y ago

It doesn't depend on modules. And in fact, you don't even have to wait until runtime and throw an exception: plugins like https://github.com/basepom/duplicate-finder-maven-plugin/wiki https://github.com/basepom/duplicate-finder-maven-plugin/wik... can enforce this at build time, with neat features like allowing two classes with the same name as long as their contents are 100% identical, or allowing specific exceptions where you can confirm they aren't going to cause problems. We run this plugin where I work. We have no plans to modularize our build since the duplicate class protection would just be worse that this plugin.

tsimionescu 5y ago

This is an implementation problem. For performance reasons, the JVM doesn't scan the entire classpath - when a Class object has to be created (to access one of it's members for the first time, such as a constructor or static method), some class loader is asked to scan the classpath until it finds that class (.class file, in .jar or directly on disk). This stops after the first successful find. This is also a reason why you can't use regular Java reflection to do something like finding all references to a method, or even finding all classes - classes are loaded on the fly, only as needed (there are libraries that modify this behavior, though).

gunnarmorling 5y ago

If these JARs are on the module path, this problem would be spotted at compile time, resulting in a failure due to the "split package" situation which has been created by having that class in more than one JAR.