How to Fix the Error: Missing Artifact com.sun:tools:jar in pom.xml Files

1. Overview

When working with older Java repositories, especially Maven projects created for Java 8 or earlier, Eclipse may report an error related to the com.sun:tools dependency:

Missing artifact com.sun:tools:jar:1.6

Similarly, an Ant build may fail with an analogous message:

Unable to locate tools.jar

On the command line, Maven reports the missing dependency and its expected path:

[ERROR] Could not resolve dependencies for project ...
[ERROR] dependency: com.sun:tools:jar:1.8 (system)
[ERROR] Could not find artifact com.sun:tools:jar:1.8 at specified path /opt/jdk-21/../lib/tools.jar

In this tutorial, we examine why the com.sun:tools:jar artifact might be missing and how to fix the problem.

2. Understanding the Problem

Older libraries and Maven projects sometimes declare tools.jar as a system dependency:

<dependency>
    <groupId>com.sun</groupId>
    <artifactId>tools</artifactId>
    <version>1.8</version>
    <scope>system</scope>
    <systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>

On JDK 8, java.home is the jre directory of the JDK, so ${java.home}/../lib/tools.jar points to the JDK path lib/tools.jar. Conversely, standalone JRE instances have no such file.

Unlike ordinary Maven dependencies, a dependency with the system scope doesn’t come from Maven Central or another repository. Instead, Maven expects the JAR to exist at the location specified by systemPath.

In JDK 8 and earlier, tools.jar was part of the JDK installation and contained classes used by Java development tools.

3. Using a JRE Instead of a JDK

A standalone Java 8 JRE doesn’t include tools.jar.

We first confirm which Java installation Maven uses:

mvn -version

Recent Maven versions label the runtime path runtime:, while older versions use Java home:. A standalone JRE path such as jre1.8.0_301 indicates a potential problem. On the other hand, jdk1.8.0_301/jre should be normal for JDK 8.

To correct the situation, we can set JAVA_HOME to the relevant JDK directory. Let’s see an example on Linux or macOS:

export JAVA_HOME=/opt/jdk1.8.0_301

In this case, JAVA_HOME points to the JDK root rather than its bin directory.

4. IDE Using the Wrong Java Installation

In Eclipse, we can first check the configured Java installations under Preferences > Java > Installed JREs and make sure an appropriate JDK is selected. For an older Eclipse version supporting Java 8, we can explicitly configure the Eclipse JVM using the -vm option in eclipse.ini:

[...]
-vm
C:\jdk1.8.0_301\bin\javaw.exe
-vmargs
[...]

After restarting Eclipse, we update or reimport the Maven project. Notably, individual Maven run configurations can have their own JRE setting.

5. Building With JDK 9 or Later

Starting with JDK 9, tools.jar no longer exists. Public tool APIs remain available through modules such as jdk.compiler (javac and Compiler Tree APIs) and jdk.attach (Attach API), without an extra JAR dependency.

Maven also prints a warning that suggests the wrong fix here:

[WARNING] 'dependencies.dependency.systemPath' for com.sun:tools:jar refers to a non-existing file /opt/jdk-21/../lib/tools.jar. Please verify that you run Maven using a JDK and not just a JRE.

Since even a full JDK 9 or later has no tools.jar, switching to a JDK doesn’t resolve it.

For projects supporting both JDK 8 and newer ones, we can move the dependency into a JDK 8-only profile:

<profiles>
    <profile>
        <id>jdk8-tools</id>
        <activation>
            <jdk>1.8</jdk>
        </activation>
        <dependencies>
            <dependency>
                <groupId>com.sun</groupId>
                <artifactId>tools</artifactId>
                <version>1.8</version>
                <scope>system</scope>
                <systemPath>${java.home}/../lib/tools.jar</systemPath>
            </dependency>
        </dependencies>
    </profile>
</profiles>

If a third-party library, Maven plugin, or framework declares com.sun:tools, we should upgrade that component to a version compatible with newer Java releases.

6. Excluding an Obsolete Dependency

To locate the declaration, let’s check the effective POM:

mvn help:effective-pom

This includes declarations from the project, its parents, and active profiles, but not transitive dependencies. For those, we use another command:

mvn dependency:tree -Dincludes=com.sun:tools

If the newer JDK already provides the functionality required by the library and the dependency on tools.jar is obsolete, we may be able to exclude it:

<dependency>
    <groupId>com.example</groupId>
    <artifactId>legacy-library</artifactId>
    <version>1.0.0</version>
    <exclusions>
        <exclusion>
            <groupId>com.sun</groupId>
            <artifactId>tools</artifactId>
        </exclusion>
    </exclusions>
</dependency>

This solution is appropriate only when the library works with the target JDK APIs. Otherwise, the Maven error may be replaced by compilation or runtime errors.

7. Avoiding Manual tools.jar Workarounds

Copying or manually installing tools.jar can make the build depend on local modifications and cause inconsistent behavior between development machines and CI environments. Maven supports system-scoped dependencies, but their use is discouraged.

8. Conclusion

In this article, we examined the Missing artifact com.sun:tools:jar and Unable to locate tools.jar errors.

For Java 8 and earlier, the problem usually means that Maven or the IDE is using a JRE instead of the required JDK, so configuring JAVA_HOME and the IDE JVM resolves the issue. Starting with Java 9, tools.jar no longer exists, so old dependencies that require it need to be upgraded, removed, or built with an appropriate legacy JDK.