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:
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
<exclusions>
<exclusion>
<!-- We have tools.jar from JDK8 in our classpath -->
<groupId>org.jmockit</groupId>
<artifactId>jmockit-attach-jdk6<</artifactId>
</exclusion>
</exclusions>
The text was updated successfully, but these errors were encountered:
Yeah, repackaging those classes (specifically, the implementation classes in "sun.tools.attach") does not work because of native methods.
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.
rliesenfeld
changed the title
Oracle attach API package rename
Conflict between Attach API classes from JDK 8's tools.jar and those in jmockit jar
Nov 2, 2017
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
com.sun.tools.attach.spi --> org.jmockit.com.sun.tools.attach.spi
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:
The text was updated successfully, but these errors were encountered: