CODEWITHSUNDEEP
javamavenexceptionpom.xml
kcs
kcs

Reputation: 31

NoClassDefFoundError due to different version of jars

I am working on maven product that use some common-collection jar with version v3.2.1, which gets downloaded from our repository. Through out the project we are using ver1.1. Now I have to use third party jar which uses common-collection with v3.2.2 due to which I'm getting NoClassDefFound exception.

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/collections/map/ReferenceMap

I cant change the version in my project. How to solve this issue?

Upvotes: 0

Views: 1000

Answers (2)

Stephen C
Stephen C

Reputation: 719199

  1. I cant change the version in my project which is v1.1

  2. Now I have to use third party jar which uses common-collection with v3.2.2

You have a hard choice to make. Either change (upgrade) the version in your project, or don't use the 3rd-party library. (This assumes that the 3rd-party library's dependency is a hard one ... which seems likely if API classes have been moved, etcetera.)

The first alternative is probably better. The longer you stay on an outdated version of the commons-collection library, the more problems like this you will encounter.

Actually, there is third possibility but it is asking for trouble. You could try to build your own version of commons-collection that is compatible with both v1.1 and v3.2.2. But here's the problem:

  • You are buying into extra work maintaining this custom version of commons-collection, for as long as you need it in your codebase. (And that could be a long time if versions of your code are long-lived; e.g. if they released to customers who have long-term support requirements.)

  • It might not work. Suppose that one part of the code requires ReferenceMap in one package, and another part requires it in another package.

Another possibility (another bad idea!) might be to do tricky things with classloaders, but that can lead to problems as well. If you two versions of the same class are loaded by different class loaders into an application, the type system will insists that they are different types. They won't be assignment compatible. Type-casts will fail unexpectedly, etcetera.

Upvotes: 1

kuhajeyan
kuhajeyan

Reputation: 11027

seems it has been moved to 

<!-- https://mvnrepository.com/artifact/org.apache.commons/commons-collections4 -->
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-collections4</artifactId>
    <version>4.1</version>
</dependency>

Upvotes: 0

Related Questions