# JAR Hell error coming when upgrading from ES 1.x to ES 2.3.5 **URL:** \ **Category:** Elasticsearch\ **Created:** [August 24, 2016, 1:48pm UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827 "2016-08-24T13:48:05Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Tipra](https://avatars.discourse-cdn.com/v4/letter/t/a9adbd/32.png) [@Tipra](https://discuss.elastic.co/u/Tipra)\ **Post date:** [August 24, 2016, 1:48pm UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/1 "2016-08-24T13:48:05Z")
I am upgrading my ElasticSearch Plugin from ES 1.x to ES 2.3.5 . I made the required changes and build it using Maven. When I tried to install the plugin with ElasticSearch , it threw following error : **ERROR: java.lang.IllegalStateException: jar hell!** **class: javax.json.Json** **jar1: C:\Users\ajaiswal\AppData\Local\Temp\4537460277365737175\temp\_name48813548** **5\javaee-api-7.0.jar** **jar2: C:\Users\ajaiswal\AppData\Local\Temp\4537460277365737175\temp\_name48813548** **5\javax.json-1.0.4.jar** I checked the binary generated from ES 1.x , it also contains the above 2 jars and binary is working fine. Why does this conflict occur in ES 2.3.5 ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [August 24, 2016, 2:35pm UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/2 "2016-08-24T14:35:09Z")
Hi @Tipra, we have added the JAR hell check in Elasticsearch 2 to avoid issues with duplicate classes on the classpath. As both JARs contain the same class, you need to get rid of one of them. You can check the dependency tree of your plugin with [`mvn dependency:tree`](https://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html) and then explicitly exclude one of them in your POM (the more likely candidate for exclusion is `javax.json-1.0.4.jar`). Daniel ---
**Author:** ![Tipra](https://avatars.discourse-cdn.com/v4/letter/t/a9adbd/32.png) [@Tipra](https://discuss.elastic.co/u/Tipra)\ **Post date:** [August 25, 2016, 10:43am UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/3 "2016-08-25T10:43:08Z")
Is there any way to disable this check in ES 2 ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [August 25, 2016, 10:57am UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/4 "2016-08-25T10:57:23Z")
Hi @Tipra, not that I'm aware of. Didn't my suggestion work? Daniel ---
**Author:** ![Tipra](https://avatars.discourse-cdn.com/v4/letter/t/a9adbd/32.png) [@Tipra](https://discuss.elastic.co/u/Tipra)\ **Post date:** [August 25, 2016, 7:49pm UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/5 "2016-08-25T19:49:42Z")
It worked but it required a lot of effort . I was just wondering if there is any way to avoid this error . ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [August 26, 2016, 6:54am UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/6 "2016-08-26T06:54:02Z")
Hi @Tipra, sorry to hear that. In Elasticsearch 2 we put a lot of effort into robustness of Elasticsearch and the JARHell check is one of the measures we took. We also run it in each build of Elasticsearch itself. The reason for that is that we want to avoid having duplicate classes on the classpath which can lead to bugs which are really hard to track down as they depend on the order in which the classes get loaded. So we want to avoid the root cause by not allowing duplicate classes at all. Thus, the only way to prevent this error is eliminating the root cause, i.e. getting rid of duplicate classes in the first place. Daniel ---
**Author:** ![Tipra](https://avatars.discourse-cdn.com/v4/letter/t/a9adbd/32.png) [@Tipra](https://discuss.elastic.co/u/Tipra)\ **Post date:** [August 26, 2016, 9:29am UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/7 "2016-08-26T09:29:36Z")
Thanks for the help 馃檪 ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [August 26, 2016, 9:45am UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/8 "2016-08-26T09:45:45Z")
Sure, you're welcome. 馃檪 ---
**Author:** ![jillesvangurp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jillesvangurp/32/3863_2.png) [@jillesvangurp](https://discuss.elastic.co/u/jillesvangurp)\ **Post date:** [August 26, 2016, 12:19pm UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/9 "2016-08-26T12:19:36Z")
Interesting. Just out of curiousity, what is Elasticsearch using to check for this? I was playing with JHades earlier and found a few potential conflicts in my own code base but it is kind of ugly since it prints to System.out and lacks a bit in flexibility. However, given the stuff it found, I need more checks like this definitely. ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [August 26, 2016, 1:06pm UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/10 "2016-08-26T13:06:40Z")
Hi @jillesvangurp, the JarHell check is contained in [Elasticsearch core](https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/bootstrap/JarHell.java) and we also run the [JarHell check as precommit task](https://github.com/elastic/elasticsearch/blob/master/buildSrc/src/main/groovy/org/elasticsearch/gradle/precommit/JarHellTask.groovy) in Gradle. Apart from that we have [many more precommit checks](https://github.com/elastic/elasticsearch/tree/master/buildSrc/src/main/groovy/org/elasticsearch/gradle/precommit) in our build. Daniel ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [August 28, 2016, 12:11am UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/11 "2016-08-28T00:11:02Z")
> [@danielmitterdorfer](#): > > So we want to avoid the root cause by not allowing duplicate classes at all. It's not that easy, see [Identical jars are not detected by jar hell 路 Issue #13604 路 elastic/elasticsearch 路 GitHub](https://github.com/elastic/elasticsearch/issues/13604) In Java, it is perfectly valid to have two identical classes on the class path, because only the first one will be loaded. This is part of the Java Language Specification, implemented by JVM caching. ES is checking for duplicate class names. It does not detect identical classes by checking the binary representations of the class. So the check is too strict. It's the binary representation the JVM caches, not the class name (which is given by classloader and binary name of class). From the Java Language specification [Chapter 12. Execution](http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.2.1) > In particular, a class loader may cache binary representations of classes and interfaces, prefetch them based on expected usage, or load a group of related classes together. These activities may not be completely transparent to a running application. By binary representation caching, the JVM ensures that identical classes are loaded only once during the JVM lifetime, no matter what class loader is in use. That's also the reason why the method `findLoadedClass` exists, which can be used to check for a class being in the cache and loaded by this class loader or not [ClassLoader (Java Platform SE 8 )](https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#findLoadedClass-java.lang.String-) ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [August 30, 2016, 6:08am UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/12 "2016-08-30T06:08:32Z")
Hi @jprante, > [@jprante](#): > > It's not that easy, see [Identical jars are not detected by jar hell 路 Issue #13604 路 elastic/elasticsearch 路 GitHub](https://github.com/elastic/elasticsearch/issues/13604) > > In Java, it is perfectly valid to have two identical classes on the class path, because only the first one will be loaded. This is part of the Java Language Specification, implemented by JVM caching. That's right. In that respect we're even more strict. So I was not entirely precise by saying we don't allow duplicate classes. What I meant was that we don't allow two classes with the same class name on the classpath. Daniel ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:24pm UTC](https://discuss.elastic.co/t/jar-hell-error-coming-when-upgrading-from-es-1-x-to-es-2-3-5/58827/13 "2017-07-05T22:24:14Z")