[Tracking] Defer JUnit 5/6 dispatch fix to upstream JDT (do not merge)

[wenytang-ms]

Status: Tracking-only PR. Not intended to merge as-is.

Decision

The dispatch regression introduced in #1820 (TestKindProvider calling CoreTestSearchEngine.hasJUnit6TestAnnotation first, which misfires on JUnit Platform 1.x fat jars) is being fixed upstream in Eclipse JDT, not in this repository. Rather than carrying a parallel sentinel-class workaround here, we will rely on the upstream fix flowing down through the normal release chain.

Upstream fixes (already merged)

• eclipse-jdt/eclipse.jdt.ui#2910 — switch anchor type from @Testable to @Test/@TestTemplate/@ClassTemplate and correct the JUnit 5 major-version baseline (1 → 5).
• eclipse-jdt/eclipse.jdt.ui@17f8fa5 (Fixes eclipse-jdt/eclipse.jdt.ui#2959) — for junit-platform-console-standalone-*.jar, read the bundled Jupiter engine version from Engine-Version-junit-jupiter instead of the platform's Specification-Version.

Together these correct CoreTestSearchEngine.hasJUnit5/6TestAnnotation for the fat-jar shape reported in #1866 and redhat-developer/vscode-java#4396.

Release chain

Eclipse 4.40 release (~Jun 2026) → JDT-LS picks up new JDT jars (target points to 4.40-I-builds, rolling) → vscode-java bumps bundled JDT-LS server → user updates vscode-java extension

Why we chose to wait

• The downstream sentinel-class check (previously proposed on this branch) is redundant once the upstream fix lands; it would add code we'd later need to clean up.
• TestKindProvider is intentionally a thin wrapper over CoreTestSearchEngine; keeping it that way avoids version-detection logic in two places.
• No reported scenarios outside junit-platform-console-standalone are affected; the upstream fix covers the actual user-visible shape.

Closure criteria

This PR / branch will be closed once:

1. ✅ A vscode-java release ships with a JDT-LS server that bundles JDT 4.40 (containing both upstream fixes above).
2. ✅ Issues Test Runner for Java Extension downloads old JUnit standalone #1866 and Cannot run JUnit tests since v1.54.0 redhat-developer/vscode-java#4396 are verified resolved against that release.

If new reports surface that are not covered by the upstream fix (e.g. third-party fat jars without Engine-Version-junit-jupiter in the manifest), we will revisit and re-introduce a targeted workaround at that time.

Related

• Test Runner for Java Extension downloads old JUnit standalone #1866
• Cannot run JUnit tests since v1.54.0 redhat-developer/vscode-java#4396
• feat: junit 6 support #1820 (regression source)

[Copilot]

Pull request overview

This PR fixes incorrect dispatch to the JUnit 6 runner by requiring confirmation that JUnit Platform 6.x APIs are actually resolvable on the project classpath, preventing runtime NoClassDefFoundError when only JUnit Platform 1.x “fat jars” are present.

Changes:

• Adds a small set of JUnit Platform 6.0-only “marker” types and checks their resolvability via IJavaProject.findType.
• Updates JUnit 5 vs JUnit 6 runner selection logic to fall back to JUnit 5 when Platform 6 markers are not present.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wenytang-ms]

Branch has been reset to main and this PR auto-closed by GitHub (empty diff). The title and description above now serve as the decision record.

Summary of the call:

• The reported regression is fully addressed upstream in eclipse-jdt/eclipse.jdt.ui#2910 + 17f8fa5.
• The downstream sentinel-class workaround that originally lived on this branch would become redundant once Eclipse 4.40 ships and flows through to vscode-java's bundled JDT-LS server.
• TestKindProvider deliberately stays as a thin wrapper over CoreTestSearchEngine so version-detection logic lives in one place.

Next steps tracked on #1866 — that issue stays open until we verify the fix against a vscode-java release that ships JDT 4.40+.