Skip to content

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

Closed
Closed
Tracking: existing JUnit Platform 1.x standalone projects routed to JUnit 6 until redhat.java picks up JDT fix#1873
Labels
ai-triagedbughigh-priorityjunittest-executionupstream

Description

@wenytang-ms
wenyt (wenytang-ms)
opened on Jun 9, 2026

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:

Upstream JDT source fix is also merged:

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

Activity

  1. wenyt (wenytang-ms)
    added
    bug
    upstream
    junit
    test-execution
    on Jun 9, 2026

  2. github-actions commented on Jun 9, 2026

    @github-actions
    github-actionsBot
    on Jun 9, 2026 – with 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

    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

    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!

  3. github-actions
    added
    ai-triaged
    high-priority
    on Jun 9, 2026

  4. wenytang-ms commented on Jun 25, 2026

    @wenytang-ms
    wenyt (wenytang-ms)
    on Jun 25, 2026
    ContributorAuthor

    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.

  5. wenyt (wenytang-ms)
    closed this as completedon Jun 26, 2026

  6. wenytang-ms commented on Jun 26, 2026

    @wenytang-ms
    wenyt (wenytang-ms)
    on Jun 26, 2026
    ContributorAuthor
    Image
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ai-triagedbughigh-priorityjunittest-executionupstream

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions