JarHell check fails for Java 9 libraries (module-info.class)

[jamesdbaker]

Elasticsearch version:

6.3.2, Build: default/zip/053779d/2018-07-20T05:20:23.451332Z, JVM: 9.0.4

JVM version:

java version "9.0.4"
Java(TM) SE Runtime Environment (build 9.0.4+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)

OS version:

Linux dendesk-0260147 4.15.0-32-generic # 35~16.04.1-Ubuntu SMP Fri Aug 10 21:54:34 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Description of the problem including expected versus actual behavior:

I'm developing a new ingest processor that uses two libraries written for Java 9. As they're written for Java 9, both have a module-info.class in the default package, but the JarHell check is detecting this and throwing an error.

java.lang.RuntimeException: found jar hell in test classpath

	at org.elasticsearch.bootstrap.BootstrapForTesting.<clinit>(BootstrapForTesting.java:95)
	at org.elasticsearch.test.ESTestCase.<clinit>(ESTestCase.java:197)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:375)
	at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:592)
Caused by: java.lang.IllegalStateException: jar hell!
class: module-info
jar1: /home/bakerj/.m2/repository/io/annot8/components/0.1-SNAPSHOT/components-0.1-SNAPSHOT.jar
jar2: /home/bakerj/.m2/repository/io/annot8/core/0.1-SNAPSHOT/core-0.1-SNAPSHOT.jar
	at org.elasticsearch.bootstrap.JarHell.checkClass(JarHell.java:273)
	at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:190)
	at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:86)
	at org.elasticsearch.bootstrap.BootstrapForTesting.<clinit>(BootstrapForTesting.java:93)
	... 4 more

As it is expected that module-info.class is found in the same place in multiple JARs, a exemption from the check is probably needed.

This has also been flagged by other users here: https://stackoverflow.com/questions/51217252/elasticsearch-6-3-0-jarhell-module-info-class

Steps to reproduce:

1. Clone the following project: https://github.com/jamesdbaker/es-extract
2. Run mvn test

[elasticmachine]

Pinging @elastic/es-core-infra

[alpar-t]

@jamesdbaker I was able to reproduce this with log4j 2.10 but not 2.11 which elasticsearch uses since 0a67cb4 . Since this is just for testing you could probably configure your pom to use it as a workaround. I will open a PR to fix jar hell soon.

[jamesdbaker]

@atorok - Thanks, I will check when I'm back in the office tomorrow. In my case though, I'm not sure log4j was the problem as the two JARs it's referencing don't include log4j. I think it's a more generic Java 9 problem. That said, hopefully whatever fix you put in place will solve both.

I'll let you know the outcome of the workaround tomorrow.

[alpar-t]

@jamesdbaker that's right, I was referring to the example from stack overflow. You could put the meta-info class in different packages to avoid the jar hell. The fix I did will fix you're project as well.

[jmmk]

@atorok Will this be backported to previous ES versions?

If I understand correctly, anyone on an older version of ES cannot have more than one instance of module-info.classon their classpath without tests failing with "found jar hell in test classpath"

[jasontedor]

We have backported this change to our 6.x branch which is the development branch for the next minor release, but we will not be taking this change back any further than that.