New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
karypid opened this Issue Oct 30, 2017 · 1 comment

Comments

2 participants
@karypid

karypid commented Oct 30, 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)

			<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 rliesenfeld added the other label Nov 2, 2017

@rliesenfeld

This comment has been minimized.

Show comment
Hide comment
@rliesenfeld

rliesenfeld Nov 2, 2017

Member

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.

Member

rliesenfeld commented Nov 2, 2017

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 rliesenfeld changed the title from Oracle attach API package rename to Conflict between Attach API classes from JDK 8's tools.jar and those in jmockit jar Nov 2, 2017

@rliesenfeld rliesenfeld self-assigned this Nov 2, 2017

@jmockit jmockit locked and limited conversation to collaborators Nov 26, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.