Cannot run JUnit tests since v1.54.0

Describe the bug
The JUnit cannot run on v1.54.0

To Reproduce
Steps to reproduce the behavior:

Unzip the project DemoJava
In VSCode open the folder DemoJava
Open sandbox/MinMaxTest.java and try to run JUnit tests

Expected behavior
JUnit tests should be able to run like in v1.53.0
A clear and concise description of what you expected to happen.

Screenshots
Error from the log file:
!ENTRY com.microsoft.java.test.plugin 4 0 2026-04-16 17:04:04.544
!MESSAGE failed to resolve the classpath.
!STACK 0
java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at com.microsoft.java.test.plugin.launchers.JUnitLaunchConfigurationDelegate.getJUnitLaunchArguments(JUnitLaunchConfigurationDelegate.java:78)
at com.microsoft.java.test.plugin.launchers.JUnitLaunchUtils.resolveLaunchArgument(JUnitLaunchUtils.java:103)
at com.microsoft.java.test.plugin.handler.TestDelegateCommandHandler.executeCommand(TestDelegateCommandHandler.java:55)
at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler$1.run(WorkspaceExecuteCommandHandler.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler.executeCommand(WorkspaceExecuteCommandHandler.java:220)
at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$4(JDTLanguageServer.java:639)
at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture$Completion.exec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Caused by: org.eclipse.core.runtime.CoreException: Cannot find 'org.junit.platform.commons.annotation.Testable' on project build path. JUnit 5 tests can only be run if JUnit 5 is on the build path.
at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.abort(JUnitLaunchConfigurationDelegate.java:839)
at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.preLaunchCheck(JUnitLaunchConfigurationDelegate.java:347)
at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.getVMRunnerConfiguration(JUnitLaunchConfigurationDelegate.java:140)
... 17 more
Root exception:
org.eclipse.core.runtime.CoreException: Cannot find 'org.junit.platform.commons.annotation.Testable' on project build path. JUnit 5 tests can only be run if JUnit 5 is on the build path.
at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.abort(JUnitLaunchConfigurationDelegate.java:839)
at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.preLaunchCheck(JUnitLaunchConfigurationDelegate.java:347)
at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.getVMRunnerConfiguration(JUnitLaunchConfigurationDelegate.java:140)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at com.microsoft.java.test.plugin.launchers.JUnitLaunchConfigurationDelegate.getJUnitLaunchArguments(JUnitLaunchConfigurationDelegate.java:78)
at com.microsoft.java.test.plugin.launchers.JUnitLaunchUtils.resolveLaunchArgument(JUnitLaunchUtils.java:103)
at com.microsoft.java.test.plugin.handler.TestDelegateCommandHandler.executeCommand(TestDelegateCommandHandler.java:55)
at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler$1.run(WorkspaceExecuteCommandHandler.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler.executeCommand(WorkspaceExecuteCommandHandler.java:220)
at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$4(JDTLanguageServer.java:639)
at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture$Completion.exec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)

If applicable, add screenshots to help explain your problem.

v 1.53.0

v 1.54.0

Environment

macOS and Linux
JDK 25
Version : 1.116.0 (Universal)
Validation : 560a9dba96f961efea7b1612916f89e5d5d4d679
Date : 2026-04-15T00:28:13Z
Electron : 39.8.7
ElectronBuildId : 13797146
Chromium : 142.0.7444.265
Node.js : 22.22.1
V8 : 14.2.231.22-electron.0
Système d’exploitation : Darwin x64 22.6.0
Java extension version: 1.54.0

Additional Information

@LeducNic

@LeducNic Could you try to replace junit-platform-console-standalone-1.13.4.jar with junit-platform-console-standalone-6.0.3.jar?

I have the same problem. Downgrading all Java extensions to versions of ~6 months ago fixes it.

@snjeza

@snjeza Could you tell me what changed between JUnit 1.13.4 and 6.0.3 that could make it work? It seems to have fixed my JUnit problem.

@CherryDT I only downgraded Language support from 1.54.0 to 1.53.0 to fix the problem. Upgrading JUnit to 6.0.3 also seems to fix the problem.

Ah, good to know - because of this issue I thought I needed to go back to 1.47.0.

@LeducNic

Same issue here, also reproduces with redhat.java 1.54.0 and is fixed by downgrading to 1.53.0. Independent of vscjava.vscode-java-test version (reproduced on 0.44.0 and 0.45.0).

Setup

OS: Windows
JDK: JavaSE-21
Eclipse-style project (.project + .classpath, no Maven/Gradle)
JUnit jar on the classpath: junit-platform-console-standalone-1.13.4.jar (declares Automatic-Module-Name: org.junit.platform.console.standalone and Multi-Release: true)
Sample .classpath

Notes

JUnit 4 tests in the same project run fine on 1.54.0 — only JUnit 5 launches fail.
The editor compiles JUnit 5 imports without errors and the Java Projects view does list org.junit.platform.commons.annotation.Testable under the jar, so JDT's compiler model resolves the type but JUnitLaunchConfigurationDelegate.preLaunchCheck's findType(...) returns null.
java.project.referencedLibraries has no effect (managed project).
Cleaning the JDT workspace and regenerating .classpath does not help.
Like @LeducNic, replacing the jar with junit-platform-console-standalone-6.0.3.jar is not an option in our environment, so for now we're pinning redhat.java to 1.53.0.

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-21"/>
<classpathentry kind="src" path="src"/>
<classpathentry kind="lib" path="C:/prereq/junit-platform-console-standalone-1.13.4.jar"/>
<classpathentry kind="output" path="bin"/>

Notes

JUnit 4 tests in the same project run fine on 1.54.0 — only JUnit 5 launches fail.
The editor compiles JUnit 5 imports without errors and the Java Projects view does list org.junit.platform.commons.annotation.Testable under the jar, so JDT's compiler model resolves the type but JUnitLaunchConfigurationDelegate.preLaunchCheck's findType(...) returns null.
java.project.referencedLibraries has no effect (managed project).
Cleaning the JDT workspace and regenerating .classpath does not help.
Like @LeducNic, replacing the jar with junit-platform-console-standalone-6.0.3.jar is not an option in our environment, so for now we're pinning redhat.java to 1.53.0.

Root cause analysis:

This is caused by a recent change in Eclipse JDT's CoreTestSearchEngine.findAnnotations() (0edde57, 203dec3c) which switched from IJavaProject.findType() (ACCEPT_ALL, no restriction checks) to NameLookup.findType() with ACCEPT_ANNOTATIONS + checkRestrictions=true.

For standalone/fat Multi-Release JARs like junit-platform-console-standalone-1.13.4.jar (which declares Automatic-Module-Name and Multi-Release: true), this new lookup fails to find @Testable even though the compiler resolves it fine.

Upstream issue filed: eclipse-jdt/eclipse.jdt.ui#2959

Workaround: Override preLaunchCheck() in vscode-java-test's JUnitLaunchConfigurationDelegate to catch the false-negative ERR_JUNIT_NOT_ON_PATH error and fall back to the old IJavaProject.findType() which works correctly with these JARs.

Hi Team, since the PR is merged, so just wait for the next preview bits to this issue, thanks
eclipse-jdt/eclipse.jdt.ui#2960

@wenytang-ms

Seems to be working for me now. @wenytang-ms does anything else need to be done here?

Unfortunately it still doesn't work on v1.55.2026053008 (pre-release).

The first time I run the tests, I get this output in the debug console:


java.lang.NoClassDefFoundError: org/junit/platform/engine/CancellationToken
	at org.eclipse.jdt.internal.junit6.runner.JUnit6TestReference.<init>(JUnit6TestReference.java:48)
	at org.eclipse.jdt.internal.junit6.runner.JUnit6TestLoader.createUnfilteredTest(JUnit6TestLoader.java:88)
	at org.eclipse.jdt.internal.junit6.runner.JUnit6TestLoader.createTest(JUnit6TestLoader.java:69)
	at org.eclipse.jdt.internal.junit6.runner.JUnit6TestLoader.loadTests(JUnit6TestLoader.java:56)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:579)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:824)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:494)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:225)
Caused by: java.lang.ClassNotFoundException: org.junit.platform.engine.CancellationToken
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	... 8 more

After that, every time I just get a skipped icon for every test and The test run did not record any output. ...

replacing the jar with junit-platform-console-standalone-6.0.3.jar upgrades the runtime to Platform 6.x, which is what the junit6 runner actually needs

Might be so, but then why does the extension by default install the incompatible 1.13 jar? I never manually installed a JUnit jar.

@datho7561

@datho7561 The original Cannot find @Testable issue is fixed by eclipse-jdt/eclipse.jdt.ui#2960, so this one can be closed.

@CherryDT the NoClassDefFoundError: CancellationToken you are now seeing is a different problem (Platform 1.13 jar vs. JDT's new JUnit 6 runner needing Platform 6.x). I will open a new issue to track it.

@CherryDT

@CherryDT vscode-java does not install JUnit jars itself. The 1.13.x jar comes from your project setup — either a Maven/Gradle dependency, an Eclipse .classpath entry, or JDT's JUnit classpath container.

Could you open a new issue for the CancellationToken problem and include: project type (Maven / Gradle / Eclipse-style), and where the junit-platform-* 1.13.x jars come from (mvn dependency:tree / gradle dependencies / .classpath)? That will help track it separately from this one.

Wait, what do you mean? I am using the "Enable Java Tests" button, see below. This auto-installs the JUnit 1.13 JAR. I only ever installed the auto-recommended Java extension pack, nothing manually regarding Java or tests.

2026-06-02_08-41-47.mp4

But regardless, I think in VSCode I should be able to run tests even from previous projects that use JUnit 5, not only JUnit 6... it's not reasonable to require updating projects because of updating an extension... not every existing project will be on the latest library versions always! (And even then, the error should be "JUnit 5 is not supported with this extension. Please run tests manually in the terminal or upgrade to JUnit 6", not a cryptic java.lang.NoClassDefFoundError or "no output generated".)

@CherryDT

@CherryDT You are right — sorry for the confusion. The jar does get installed by vscode-java-test's "Enable Java Tests" action (it downloads the latest junit-platform-console-standalone from Maven Central, which is currently Platform 1.13.x). And you are right that existing JUnit 5 projects should keep working.

This is actually a regression in vscode-java-test (introduced by JUnit 6 support), not in vscode-java. Could you open an issue at microsoft/vscode-java-test#1866 with your video and details so we can track and fix it there? Thanks!

But then again why does it work with latest vscode-java-test when I downgrade vscode-java to 1.53? So, clearly, this extension has a part in this. I'm confused how this is a pure vscode-java-test issue then, am I missing something?

Also, your message feels a bit incoherent (what does "open an issue at [link to existing issue about same thing]" even mean), and I notice you like using the em-dash character — much... are you an AI, if you don't mind me asking? I would like to make sure my messages are read by a human being! (If not, sorry for asking.)

@CherryDT

@CherryDT You're right that vscode-java is part of the chain, and sorry the earlier comments were confusing on that.

What actually happens: the JUnit6TestReference class (the one importing CancellationToken) was added on the JDT-LS server bundled with vscode-java 1.54. On 1.53 that class wasn't there yet, so the launcher fell back to the JUnit 5 path and your 1.13.x jar worked. After 1.54 the JUnit 6 runner is present, plus there's an upstream JDT routing bug (eclipse-jdt/eclipse.jdt.ui#2959) that misidentifies anyjunit-platform-console-standalone jar as Platform 6.x.
So a 1.13 jar gets handed to the new runner, which can't find CancellationToken.

That's why downgrading to 1.53 hid the symptom.

The fix for your case is the upstream JDT routing fix, not a workaround on the vscode-java-test side. Once that fix is released and the next JDT-LS server is bundled into vscode-java, your existing 1.13 jar will be routed back to the JUnit 5 runner the way it used to be. You do not need to migrate to JUnit 6 or swap any jars. Until then, staying on 1.53 is a reasonable short-term option.

(Separately, microsoft/vscode-java-test#1868 changes "Enable Java Tests" so fresh projects pick the latest stable rather than the 1.13.0-M3 milestone returned by the now-stale Maven search index. That is a quality fix for new setups and unrelated to your existing project.)

Closing this issue since the original Cannot find @Testable part is fixed, and the new CancellationToken symptom is tracked upstream at eclipse-jdt/eclipse.jdt.ui#2959. Sorry again for the earlier misdirection about "open an issue".

@datho7561

The remaining NoClassDefFoundError: CancellationToken is fixed in Test Runner for Java pre-release 0.45.2026060403. Root cause was that Enable Java Tests downloaded junit-platform-console-standalone-1.13.x (Platform 1.x, no CancellationToken) even when JDT routed through the JUnit 6 runner.

Fixes:

Picker now resolves the latest version from maven-metadata.xml per chosen kind (JUnit 5 → 1.14.4, JUnit Jupiter 6 → 6.1.0).
JUnit Jupiter 6 is now a separate option (recommended).

For already-broken projects: delete the old lib/junit-platform-console-standalone-1.13.*.jar, then re-run "Enable Java Tests" and pick the version matching your code.

@datho7561 just close this issue as fixed — please reopen if it reproduces on a clean setup.

This issue is not fixed and somehow just randomly started happening to my JUnit 5 tests.

I am uncertain if it has anything to do with updating to Visual Studio Code 1.126, but rolling back VSC itself did not fix the issue and I have no interest spending any more time on this.

The workaround is to downgrade to redhat.java 1.53.0:

All Java extensions remain on the latest version:

Hope this saves someone 2 hours of troubleshooting.

@kathyrollo

@kathyrollo Thanks for the update.

The compatible fix requires both sides to be updated:

redhat.java 1.55.0 or newer
Test Runner for Java 0.46.0 or newer

redhat.java 1.55.0 contains the JDT-LS/JDT fix, and Test Runner for Java 0.46.0 contains the matching fixes for test discovery and bundled JUnit/ASM dependencies. I verified this combination with a plain Eclipse Java project using junit-platform-console-standalone-1.13.4.jar, and the JUnit 5 tests were discovered correctly.

Could you please update Test Runner for Java to 0.46.0 and try again? If it still reproduces with redhat.java >= 1.55.0 and Test Runner for Java >= 0.46.0, please share a small sample project and the Java extension logs so we can investigate the remaining case.

@wenytang-ms

Hi @wenytang-ms ,

I confirm this combination works:

Test Runner in VSC:

Thanks.

@datho7561

@datho7561 you may close this issue.

Hello,
on my side I still have the problem, and it concerns a lot of users in my company and the only workaround that work is to use 1.53 version of the java extension.
I try to share a reproductible environment.
Also, I've heard some eclipse users have a similar issue updating their eclipse environment

java-test-issue.zip

Detect renamed junit-platform-console-standalone JARs via manifest

It is worth mentioning that our company has renamed this jar to junit4.jar ^^ in the above workspace sample I've renamed the file to org.junit.platform.console.standalone-1.13.4.jar so that you view the right name/version of this jar. Hope it will guide you to the right fix. Thank you for your support

Detect renamed junit-platform-console-standalone JARs via manifest

Navigation Menu

Repository navigation

Cannot run JUnit tests since v1.54.0 #4396

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Cannot run JUnit tests since v1.54.0 #4396

Description

Activity

snjeza commented on Apr 18, 2026

CherryDT commented on Apr 20, 2026

LeducNic commented on Apr 20, 2026

CherryDT commented on Apr 20, 2026

llgcode commented on Apr 22, 2026

wenytang-ms commented on Apr 23, 2026

wenytang-ms commented on May 6, 2026

datho7561 commented on May 21, 2026

CherryDT commented on Jun 1, 2026

CherryDT commented on Jun 2, 2026

wenytang-ms commented on Jun 2, 2026

wenytang-ms commented on Jun 2, 2026

CherryDT commented on Jun 2, 2026

wenytang-ms commented on Jun 2, 2026

CherryDT commented on Jun 2, 2026

wenytang-ms commented on Jun 3, 2026

wenytang-ms commented on Jun 4, 2026

kathyrollo commented on Jun 26, 2026

wenytang-ms commented on Jun 26, 2026

kathyrollo commented on Jun 26, 2026

wenytang-ms commented on Jun 26, 2026

llgcode commented on Jun 29, 2026

llgcode commented on Jun 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions