Tracking: existing JUnit Platform 1.x standalone projects routed to JUnit 6 until redhat.java picks up JDT fix

[wenytang-ms]

Summary

This issue tracks the remaining end-to-end failure for existing projects that already reference junit-platform-console-standalone-1.13.x.jar.

Symptom:

• Tests are discovered.
• Running them uses the JDT JUnit 6 runner path, for example org.eclipse.jdt.internal.junit6.runner.JUnit6TestReference.
• The run fails with:

java.lang.NoClassDefFoundError: org/junit/platform/engine/CancellationToken

That means a JUnit Platform 1.x standalone jar, which bundles Jupiter 5.x, is being launched through the JUnit 6 runner.

Expected behavior

Existing projects using junit-platform-console-standalone-1.13.x should continue to run as JUnit 5 projects. Users should not have to migrate existing projects to JUnit Jupiter 6 just because the VS Code Java extensions were updated.

Current status

vscode-java-test side changes are done:

• fix: use maven-metadata.xml to look up latest test framework version #1868 / Test Runner for Java Extension downloads old JUnit standalone #1866: Enable Java Tests now uses maven-metadata.xml instead of the stale Maven search index, and JUnit Jupiter 5 and JUnit Jupiter 6 are separate choices.
• fix: ship org.objectweb.asm bundles to satisfy Jacoco 0.8.14 (#1866) #1872: the extension now ships the ASM bundles required by the test plugin/Jacoco startup path.

Upstream JDT source fix is also merged:

• CoreTestSearchEngine.findAnnotations() fails to find @Testable in standalone/fat Multi-Release JARs eclipse-jdt/eclipse.jdt.ui#2959
• Use bundled Jupiter version for JUnit platform console standalone JARs eclipse-jdt/eclipse.jdt.ui#2960

That JDT fix detects junit-platform-console-standalone-* jars using the manifest Engine-Version-junit-jupiter entry, so a 1.13.x standalone jar is classified as Jupiter 5.x instead of being treated as JUnit 6.

Remaining release-chain step:

1. JDT-LS picks up the JDT fix.
2. redhat.java ships a build containing that JDT-LS update.
3. Users update redhat.java and verify existing 1.13.x standalone projects run through the JUnit 5 path.

Until that build is available, users can still hit the CancellationToken failure even with the latest vscode-java-test.

Workarounds

• If existing project dependencies must stay unchanged, stay on redhat.java 1.53 for now.
• If changing project dependencies is acceptable, replace the old standalone jar with JUnit Jupiter 6 by running Enable Java Tests again and choosing JUnit Jupiter 6.

Closure criteria

Close this issue only after a redhat.java build containing the JDT/JDT-LS fix is available and an existing project using junit-platform-console-standalone-1.13.x is verified to run with the JUnit 5 runner.

Related

• Cannot run JUnit tests since v1.54.0 redhat-developer/vscode-java#4396
• Test Runner for Java Extension downloads old JUnit standalone #1866
• fix: use maven-metadata.xml to look up latest test framework version #1868
• fix: ship org.objectweb.asm bundles to satisfy Jacoco 0.8.14 (#1866) #1872
• CoreTestSearchEngine.findAnnotations() fails to find @Testable in standalone/fat Multi-Release JARs eclipse-jdt/eclipse.jdt.ui#2959
• Use bundled Jupiter version for JUnit platform console standalone JARs eclipse-jdt/eclipse.jdt.ui#2960

[github-actions]

Hi wenyt (@wenytang-ms), I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

Workarounds

• Continue using redhat.java 1.53 until a build containing the JDT/JDT-LS fix is released.
  • Cannot run JUnit tests since v1.54.0 redhat-developer/vscode-java#4396: tracks shipping the fix in redhat.java
• If you can change project dependencies, rerun Enable Java Tests and choose JUnit Jupiter 6 to pull in the new standalone JAR.

Next Steps

• Wait for a redhat.java update that bundles the upstream JDT-LS fix. Once available, projects using junit-platform-console-standalone-1.13.x will automatically run via the JUnit 5 runner and avoid the CancellationToken error.

Key References

• Test Runner for Java Extension downloads old JUnit standalone #1866: switch to maven-metadata.xml for JUnit version detection
  Test Runner for Java Extension downloads old JUnit standalone #1866
• fix: use maven-metadata.xml to look up latest test framework version #1868: separate choices for JUnit 5 and JUnit 6
  fix: use maven-metadata.xml to look up latest test framework version #1868
• fix: ship org.objectweb.asm bundles to satisfy Jacoco 0.8.14 (#1866) #1872: ship ASM bundles required by the test plugin/Jacoco startup path
  fix: ship org.objectweb.asm bundles to satisfy Jacoco 0.8.14 (#1866) #1872
• CoreTestSearchEngine.findAnnotations() fails to find @Testable in standalone/fat Multi-Release JARs eclipse-jdt/eclipse.jdt.ui#2959: detect junit-platform-console-standalone-* via manifest entry
  CoreTestSearchEngine.findAnnotations() fails to find @Testable in standalone/fat Multi-Release JARs eclipse-jdt/eclipse.jdt.ui#2959
• Use bundled Jupiter version for JUnit platform console standalone JARs eclipse-jdt/eclipse.jdt.ui#2960: classify 1.x standalone JARs as Jupiter 5.x
  Use bundled Jupiter version for JUnit platform console standalone JARs eclipse-jdt/eclipse.jdt.ui#2960

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!

[wenytang-ms]

Verified against the new redhat.java 1.55 bits from https://github.com/redhat-developer/vscode-java/actions/runs/28102068371

Validation details:

• The VSIX contains JDT-LS 1.59.0.202606241329 and org.eclipse.jdt.junit.core_3.14.300.v20260530-0929.jar.
• CoreTestSearchEngine.class in that bundle contains the standalone-JAR fix paths: Engine-Version-junit-jupiter, junit-platform-console-standalone, and getJUnitVersionFromManifest.
• I ran a smoke test with a plain Eclipse Java project (.project / .classpath) referencing junit-platform-console-standalone-1.13.4.jar.
• JDT-LS discovery classified MinMaxTest as testKind: 0 (JUnit 5), not testKind: 3 (JUnit 6), and discovered the test method successfully.
• The logs did not contain CancellationToken, NoClassDefFoundError, JUnit6TestReference, or the old Cannot find org.junit.platform.commons.annotation.Testable failure.

So the release-chain dependency for this issue is satisfied in these 1.55 bits: existing junit-platform-console-standalone-1.13.x projects are no longer misclassified as JUnit 6 by JDT-LS. We can close this once redhat.java 1.55 is published/available to users.

[wenytang-ms]