Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Conflict between Attach API classes from JDK 8's tools.jar and those in jmockit jar #475
JMockIt bundles com.sun.tools.attach and com.sun.tools.attach.spi from the JDK (specifically version 6) https://docs.oracle.com/javase/8/docs/jdk/api/attach/spec/index.html
This can cause disruption in projects that use it and rely on newer versions of it.
I have seen in other projects that bundle code like this, it is common practice to rename packages into the importing project's namespace, so that it does not interfere with client code. So I suggest you rename:
com.sun.tools.attach --> org.jmockit.com.sun.tools.attach
This way JMockIt code can use it's private copy, while at the same time leaving client code that happens to use both JMockIt and the Attach API unaffected.
EDIT: if the package cannot be renamed due to native library loading that expects specific names, you can alternatively distribute 2 artifacts
Artifact 1: (the regular library)
Artifact 2: (1 above pulls this one as it dependency):
This way one would be able to do this:
Yeah, repackaging those classes (specifically, the implementation classes in "sun.tools.attach") does not work because of
Distributing two separate artifacts is not an option, as it wouldn't really solve anything. Most users would not notice the existence of the secondary jar (since, usually, they don't read documentation). Besides, most users would never need to worry about this.
There is a viable solution, though, which is to simply upgrade JMockit's copy of the Attach API classes, from the JDK 6 version it currently embeds to the one from JDK 8.