Conflict between Attach API classes from JDK 8's tools.jar and those in jmockit jar

[karypid]

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)

			<groupId>org.jmockit</groupId>
			<artifactId>jmockit</artifactId>

Artifact 2: (1 above pulls this one as it dependency):

			<groupId>org.jmockit</groupId>
			<artifactId>jmockit-attach-jdk6</artifactId>

This way one would be able to do this:

            <exclusions>
                <exclusion>
                    <!-- We have tools.jar from JDK8 in our classpath -->
                    <groupId>org.jmockit</groupId>
                    <artifactId>jmockit-attach-jdk6<</artifactId>
                </exclusion>
            </exclusions>

[rliesenfeld]

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]

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.