Jar picks wrong dependency version from on-premise lib

Question

I have a system where modules are build and deployed into a system. All jars are located under lib folder in that system. My jar has a dependency to commons-io of version 2.0 and other module has dependency to commons-io, too but of version 1.1. So, both versions are deployed to lib folder. There is a method that exists in 2.0 but not in 1.1. When I ran my own jar, it goes and picks old version which is 1.1 ,and it causes NoSuchMethodError. I am using maven. Is there a way to force my module to use the version that I set in pom.xml? I cannot ask other module maintainer for a version change as this lib comes as 4th level transitive dependency.

Answer 1

If you have two different versions of the same JAR in the lib folder and load the whole lib folder onto the classpath, then you are playing roulette.

The JVM may pick one or the other version, and while in theory, you probably can figure out the rules, in practise, it is just unstable.

So, what can you do? Some alternatives:

• Remove the version 1.1 from the lib folder and see whether the other module runs with 2.0 as well (often, version upgrades are more or less compatible)
• Use two different lib folders, or construct the classpath manually for the two JARs. Only possible if they do not run in the same JVM.
• Use the maven shade plugin to shade the required library into your own JAR.
• Most of commons-io is obsolete by now because adequate classes/methods are already part of the JDK (from Java 8 upwards). So you might just be able to remove commons-io from your project and do the file handling with Java itself.