Skip to content

Resolve symbolic links before comparing the test JDK with Maven's JDK - #3475

Open
cwegener-79 wants to merge 1 commit into
apache:masterfrom
cwegener-79:resolve-symlinked-jdk-home
Open

cwegener-79 wants to merge 1 commit into
apache:masterfrom
cwegener-79:resolve-symlinked-jdk-home

Conversation

@cwegener-79

Copy link
Copy Markdown
Contributor

ForkStarter#isForkJvmDifferentFromBuildJvm compares the JDK home of the tests with Maven's own JDK home using plain File#equals:

private boolean isForkJvmDifferentFromBuildJvm() {
    File testsJdkHome = forkConfiguration.getJdkForTests().getJdkHome();
    return testsJdkHome != null && !testsJdkHome.equals(toJdkHomeFromJre());
}

Two different spellings of the same directory therefore count as two different JDKs. This is easy to hit on CI machines, where the JDK is often reached through a symbolic link or an automounted path.

Since #3444, that comparison decides whether Surefire starts an extra short-lived fork to list the test classes. When both paths refer to the same JDK, that fork is pure overhead: one additional JVM startup per module, for every build.

What this PR does

Canonicalizes both paths before comparing them, falling back to the absolute path when the file system cannot be queried (unreadable directory, missing path).

Verification

  • New unit tests in ForkStarterTest cover relative segments, a symbolic link (skipped via assumption on platforms that do not allow creating one) and two genuinely different directories.
  • Checked manually on Linux with a project using forkCount=4 and <jvm> pointing at a symlink to the running JDK:
    • before: an extra fork is started and target/surefire/surefire-discovered-tests*.txt is written,
    • after: neither happens, and the tests run exactly as before.

No behaviour changes when the test JDK really is a different one - the listing fork is still used in that case.

Following this checklist to help us incorporate your
contribution quickly and easily:

  • Each commit in the pull request should have a meaningful subject line and body.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Run mvn clean install to make sure basic checks pass. A more thorough check will
    be performed on your pull request automatically.
  • You have run the integration tests successfully (mvn -Prun-its clean install). --> Was not possible in my infrastructure

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

ForkStarter#isForkJvmDifferentFromBuildJvm compared the JDK home of the
tests with Maven's own JDK home by plain File#equals. Two different
spellings of the same directory - a symbolic link or an automounted path,
for instance - therefore counted as two different JDKs.

That is common on CI machines: when the jvm parameter points at
/opt/components/java/jdk8u492-b09/bin/java while the running JVM reports
/srv/autofs/components/java/jdk8u492-b09/jre, both refer to the same JDK.
Surefire then started an extra short-lived fork to list the test classes,
which is pure overhead for every module of every build.

Canonicalize both paths before comparing them, falling back to the
absolute path when the file system cannot be queried.
@cwegener-79
cwegener-79 force-pushed the resolve-symlinked-jdk-home branch 2 times, most recently from e4d719a to a12bf01 Compare September 17, 2026 09:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant