elastic/elasticsearch · error · IllegalStateException

We should be comparing different jars, but original and new

Error message

We should be comparing different jars, but original and new jars were both: ${newJarFile.getAbsolutePath()}

What it means

Thrown as IllegalStateException in JarApiComparisonTask.compare() when the oldJar and newJar have the same filename. Comparing a jar against itself (or two jars with identical names) is a no-op that would always pass and mask real API changes; the guard refuses to run a meaningless comparison. This typically indicates the old and new configurations resolve to the same artifact.

Source

Thrown at build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/JarApiComparisonTask.java:75

 *     an API.</li>
 *     <li>Finally, moving a method up the class hierarchy is not really a breaking change,
 *     but it will trip this test.</li>
 * </ol>
 */
@CacheableTask
public abstract class JarApiComparisonTask extends PrecommitTask {

    @TaskAction
    public void compare() {
        FileCollection fileCollection = getOldJar().get();
        File newJarFile = getNewJar().get().getSingleFile();

        Set<String> oldJarNames = fileCollection.getFiles().stream().map(File::getName).collect(Collectors.toSet());
        if (oldJarNames.size() > 1) {
            throw new IllegalStateException("Expected a single original jar, but found: " + oldJarNames);
        }
        if (oldJarNames.contains(newJarFile.getName())) {
            throw new IllegalStateException(
                "We should be comparing different jars, but original and new jars were both: " + newJarFile.getAbsolutePath()
            );
        }

        JarScanner oldJS = new JarScanner(getOldJar().get().getSingleFile().getPath());
        JarScanner newJS = new JarScanner(newJarFile.getPath());
        try {
            JarScanner.compareSignatures(oldJS.jarSignature(), newJS.jarSignature());
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

    @CompileClasspath
    public abstract Property<FileCollection> getOldJar();

    @CompileClasspath
    public abstract Property<FileCollection> getNewJar();

View on GitHub (pinned to db6a809a66)

Solutions

1. Verify getOldJar() resolves to a genuinely different (older) version's jar — check the BWC version string and dependency coordinates.
2. Ensure the old-version download/build actually produced a distinct file (different version in the filename).
3. Inspect newJarFile.getAbsolutePath() in the error and confirm getOldJar() doesn't resolve the same path.
4. If comparing against a baseline jar with the same name, place them in different directories and disambiguate, or rename.

Example fix

// before: both resolve current version
getOldJar().from(configurations.named("runtimeClasspath"))
getNewJar().from(tasks.named("jar"))
// both named elasticsearch-server-9.0.0.jar → throws

// after: oldJar resolves the previous BWC version
getOldJar().from(configurations.named("bwcPrevApiJar"))  // elasticsearch-server-8.x.jar
getNewJar().from(tasks.named("jar"))                    // elasticsearch-server-9.0.0.jar

String newName = getNewJar().get().getSingleFile().getName();
Set<String> oldNames = getOldJar().get().getFiles().stream().map(File::getName).collect(Collectors.toSet());
if (oldNames.contains(newName)) {
    throw new IllegalStateException("old and new jars have the same name: " + newName + " — versions not distinct?");
}

When it happens

Trigger: At line 74, oldJarNames.contains(newJarFile.getName()) is checked. If the new jar's filename matches the (single) old jar's filename, the exception fires with the new jar's absolute path. Triggered when both properties point to the same file, or when version-stripped names collide.

Common situations: The oldJar and newJar configurations both resolve the current version's jar (BWC version not actually different); a copy-paste error wiring both properties to the same configuration; the BWC old-version download failed and fell back to the current jar; version classifiers are missing so both resolve to 'elasticsearch-server-9.0.0.jar'.

Related errors

• Expected a single original jar, but found: ${oldJarNames}
• classname is a required setting for esplugin
• classname is a forbidden for stable esplugin
• invalid deploymentTarget '{}', expected one of {}
• Number of nodes should be >= 1 but was {} for {}

AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12). Data as JSON: /api/errors/1595c87cd19a987a. Report an issue: GitHub.