Test Runner for Java Extension downloads old JUnit standalone

When we create a "no build tools" Java project and, after that, try to "Enable Java Tests" using the "test icon", it downloads the "junit-platform-console-standalone-1.13.0-M3.jar" file instead of JUnit 6 versions. This old version is not working with most recent Test Runner and Language Support for Java Extensions. (i'm using Extension Pack for Java 0.31.0, Language Support 1.54.0 and Test Runner 0.45.0).

I know we can fix it by manually downloading more recent standalones, or creating Maven/Gradle projects. But when the platform is being used to teach some dozen first-term students, creating a Maven project, keep in mind the directories and packages structure etc are annoying and time consuming distractions.

Besides, if there is a plugin to make things easier for everyone (such as downloading and including the reference to the Junit jar), it should work properly. So, please, take a few minutes to fix this.

Joao Caram (@joaocaram)

Hi Joao Caram (@joaocaram), 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.

Suggestions

Use a build tool (Maven/Gradle) project so that test dependencies are declared in your pom.xml/build.gradle instead of relying on the standalone JAR download.
As a temporary workaround, manually download a newer junit-platform-console-standalone JAR (e.g. v1.9.2) from https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone/ and replace the junit-platform-console-standalone-1.13.0-M3.jar in your project’s lib folder.
Upvote or comment on the existing feature request to bump the default standalone JAR version in the Test Runner extension so the next release ships a recent JUnit platform.

References

VS Java Test extension is unable to detect JUnit tests (#1498) – explains the “Enable Java Tests” workflow for no-build-tools projects and how the extension downloads the standalone JAR.

No duplicates found.

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!

Hi AI/bot @github-actions

* Upvote or comment on the existing feature request to bump the default standalone JAR version in the Test Runner extension so the next release ships a recent JUnit platform.

Sorry, I may be missing something here. Where do I find the feature request so I can upvote?

Thanks

Looked into this. The root cause is actually two bugs working together:

Enable Java Tests downloads a Platform 1.x jar (testDependenciesCommands.ts:81,138-142): the JUnit5 branch asks Maven Central's search API for latestVersion of org.junit.platform:junit-platform-console-standalone, which currently returns 1.13.x.
Test kind dispatch then misclassifies that 1.x jar as JUnit 6 (TestKindProvider.java:48-53, introduced in feat: junit 6 support #1820): we delegate to CoreTestSearchEngine.hasJUnit6TestAnnotation. For junit-platform-console-standalone-*.jar the filename does not match the junit-platform-commons prefix and the manifest has no Specification-Version, so JDT cannot determine the platform version and falls through, returning true. The launcher then picks org.eclipse.jdt.junit6.runtime, which hard-requires Platform 6.0 APIs (CancellationToken, LauncherExecutionRequest…) → NoClassDefFoundError at runtime.

Same root cause as the NoClassDefFoundError: org/junit/platform/engine/CancellationToken reported in redhat-developer/vscode-java#4396.

I will send a PR shortly to add a Platform 6 sentinel check in TestKindProvider so 1.x fat jars correctly dispatch to the JUnit 5 runner. That fixes the runtime failure for both new Enable Tests installs and existing JUnit 5 projects.

fix: only dispatch to JUnit 6 runner when Platform 6 is on the classpath

Same issue here (see redhat-developer/vscode-java#4396 (comment)).

I was told it's a bug with vscode-java-test, not vscode-java, but if I downgrade vscode-java to 1.53, it all works, so I'm not sure what exactly the problem is.

Anyway, I believe a) existing projects using the 1.13 JAR should continue working, and b) "Enable Java tests" should not install something by default that is broken.

Update: after closer analysis we are going to rely on the upstream JDT fix rather than ship a downstream workaround in this repo.

Upstream fixes already merged:

eclipse-jdt/eclipse.jdt.ui#2910 — fixes the annotation-anchor and JUnit 5 major-version baseline.
eclipse-jdt/eclipse.jdt.ui@17f8fa5 (Fixes eclipse-jdt/eclipse.jdt.ui#2959) — for junit-platform-console-standalone-*.jar, reads the bundled Jupiter engine version from the manifest's Engine-Version-junit-jupiter attribute so version detection returns 5.x instead of mistaking the platform's 1.x.

Why not a downstream workaround: TestKindProvider is intentionally a thin wrapper over CoreTestSearchEngine.hasJUnit5/6TestAnnotation. Duplicating sentinel-class checks here would just need to be cleaned up later once the upstream fix flows down, and would not help any caller that goes through CoreTestSearchEngine directly.

Release chain (expected timeline):

Eclipse 4.40 release (~mid-June 2026)
JDT-LS picks up new JDT jars (target tracks 4.40-I-builds)
vscode-java bumps the bundled JDT-LS server jar
End users update their vscode-java extension

This issue will stay open until step 4 is verified. If anyone hits a fat-jar shape that is not junit-platform-console-standalone-*.jar and still misdispatches to the JUnit 6 runner after upgrading, please post the project setup here — we'll revisit a downstream check at that point.

(The previously proposed PR #1867 has been converted into a tracking record for this decision.)

test: guard against stale Maven Central data sources

fix: use maven-metadata.xml to look up latest test framework version (#…

wenyt (@wenytang-ms)

Hi wenyt (@wenytang-ms),

Please install the pre-release and verify. Closing as fixed — feel free to reopen if it still misbehaves.

It worked perfectly with the pre-release. The JUnit 6 recommendation is a nice plus. Thank you!

I tried updating both vscode-java and vscode-java-test to pre-release but it doesn't work, now the test options no longer show up at all and I have this in the output console:

Jun 04, 2026 5:30:31 PM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic
[Error - 5:30:35 PM] Jun 4, 2026, 5:30:34 PM FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: com.microsoft.java.test.plugin [124]
  Unresolved requirement: Require-Bundle: org.objectweb.asm; bundle-version="[9.9.0,9.10.0)"

	at org.eclipse.osgi.container.Module.start(Module.java:495)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:2110)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:146)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2101)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:2041)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:2003)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1915)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:341)

[Error - 5:30:36 PM] Jun 4, 2026, 5:30:36 PM Failed to load extension bundles 
org.eclipse.core.runtime.CoreException: Load bundle list
	at org.eclipse.jdt.ls.core.internal.handlers.BundleUtils.loadBundles(BundleUtils.java:175)
	at org.eclipse.jdt.ls.core.internal.handlers.InitHandler.handleInitializationOptions(InitHandler.java:100)
	at org.eclipse.jdt.ls.core.internal.handlers.BaseInitHandler.initialize(BaseInitHandler.java:68)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.initialize(JDTLanguageServer.java:287)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$recursiveFindRpcMethods$0(GenericEndpoint.java:65)
	at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.request(GenericEndpoint.java:128)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleRequest(RemoteEndpoint.java:271)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:201)
	at org.eclipse.jdt.ls.core.internal.ParentProcessWatcher.lambda$1(ParentProcessWatcher.java:86)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:185)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:97)
	at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:114)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Contains: Bundle startup failed reference:file:/home/david/.vscode-server/extensions/vscjava.vscode-java-test-0.45.2026060403/server/com.microsoft.java.test.plugin-0.43.1.jar
org.osgi.framework.BundleException: Could not resolve module: com.microsoft.java.test.plugin [152]
  Unresolved requirement: Require-Bundle: org.objectweb.asm; bundle-version="[9.9.0,9.10.0)"

	at org.eclipse.osgi.container.Module.start(Module.java:495)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:471)
	at org.eclipse.jdt.ls.core.internal.handlers.BundleUtils.startBundles(BundleUtils.java:310)
	at org.eclipse.jdt.ls.core.internal.handlers.BundleUtils.loadBundles(BundleUtils.java:173)
	at org.eclipse.jdt.ls.core.internal.handlers.InitHandler.handleInitializationOptions(InitHandler.java:100)
	at org.eclipse.jdt.ls.core.internal.handlers.BaseInitHandler.initialize(BaseInitHandler.java:68)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.initialize(JDTLanguageServer.java:287)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$recursiveFindRpcMethods$0(GenericEndpoint.java:65)
	at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.request(GenericEndpoint.java:128)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleRequest(RemoteEndpoint.java:271)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:201)
	at org.eclipse.jdt.ls.core.internal.ParentProcessWatcher.lambda$1(ParentProcessWatcher.java:86)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:185)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:97)
	at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:114)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Contains: Bundle startup failed reference:file:/home/david/.vscode-server/extensions/vscjava.vscode-java-test-0.45.2026060403/server/org.jacoco.core_0.8.14.202510111229.jar
org.osgi.framework.BundleException: Could not resolve module: org.jacoco.core [177]
  Unresolved requirement: Import-Package: org.objectweb.asm; version="[9.9.0,9.10.0)"

	at org.eclipse.osgi.container.Module.start(Module.java:495)
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:471)
	at org.eclipse.jdt.ls.core.internal.handlers.BundleUtils.startBundles(BundleUtils.java:310)
	at org.eclipse.jdt.ls.core.internal.handlers.BundleUtils.loadBundles(BundleUtils.java:173)
	at org.eclipse.jdt.ls.core.internal.handlers.InitHandler.handleInitializationOptions(InitHandler.java:100)
	at org.eclipse.jdt.ls.core.internal.handlers.BaseInitHandler.initialize(BaseInitHandler.java:68)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.initialize(JDTLanguageServer.java:287)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$recursiveFindRpcMethods$0(GenericEndpoint.java:65)
	at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.request(GenericEndpoint.java:128)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleRequest(RemoteEndpoint.java:271)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:201)
	at org.eclipse.jdt.ls.core.internal.ParentProcessWatcher.lambda$1(ParentProcessWatcher.java:86)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:185)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:97)
	at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:114)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

Jun 04, 2026 5:30:37 PM com.microsoft.java.debug.plugin.internal.JavaDebuggerServerPlugin start
INFO: Starting com.microsoft.java.debug.plugin

No user-visible error beyond the log.

Please advise.

fix: ship org.objectweb.asm bundles to satisfy Jacoco 0.8.14 (#1866) (#…

David Trapp (@CherryDT)

David Trapp (@CherryDT)
fixed on #1872, will ship prerelease tomorry.

David Trapp (@CherryDT)

David Trapp (@CherryDT) try install this extension to verify this issue

Now the tests show up again, but they still fail with the error from before:


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:580)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:490)
	... 8 more

David Trapp (@CherryDT)

David Trapp (@CherryDT)
Looks like your project may still be using the old JUnit standalone jar.

Could you try this:

Delete the old junit-platform-console-standalone-1.13.*.jar from your project’s lib folder.
Check .classpath and remove the entry pointing to that old jar if it’s still there.
Run Enable Java Tests again.
Choose JUnit Jupiter 6 (recommended).
Reload VS Code, or run Java: Clean Java Language Server Workspace.

After that, please check that the project is using junit-platform-console-standalone-6.1.0.jar.

If it still fails, could you share your .classpath and the list of jars under lib?

Yes, it's using the old JUnit standalone jar, I'm not at liberty to change that for all projects I'm working on.

But why would this be a problem? Again, shouldn't the extension keep working with existing projects that have the 1.13 standalone JAR that used to work fine? In my opinion this is a regression. It should detect the JUnit version and use the code path that always worked before.

I feel like we are going in circles, because you already agreed with me on that point before, here: redhat-developer/vscode-java#4396 (comment)

And you are right that existing JUnit 5 projects should keep working.

And here: redhat-developer/vscode-java#4396 (comment)

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.

(I still get the feeling I'm talking with an AI. Please, please, make sure a human is reading my messages, it's incredibly frustrating. If I'm wrong - sorry, no insult intended, and I appreciate the work you do, I just really don't like the feeling of going in circles.)

You’re right. Replacing the jar is only a workaround, not the real fix.

The expected behavior is still that existing projects using junit-platform-console-standalone-1.13.x continue to work as JUnit 5 projects. They should not be forced to migrate to JUnit 6.

The real fix is in the JDT/JDT-LS side: the standalone 1.13.x jar needs to be detected as Jupiter 5.x and routed to the JUnit 5 runner. That fix has already been made upstream, but it still needs to flow through JDT-LS and then into a redhat.java / vscode-java release.

To be transparent, I maintain the vscode-java-test side, but I do not maintain JDT-LS or the redhat.java release pipeline, so I cannot directly control when that fix ships there. I can only track it and verify once a build containing the fix is available.

So for now there are two options:

If changing the project dependency is acceptable as a temporary workaround, remove the old junit-platform-console-standalone-1.13.x.jar, run Enable Java Tests again, and choose JUnit Jupiter 6.
If the project must stay unchanged, please stay on redhat.java 1.53 for now. Once vscode-java ships a JDT-LS build containing the upstream fix, the existing 1.13.x jar should work again without changing project dependencies.

We’ll keep this tracked as a release-chain issue, not as “fixed by replacing the jar”.

OK, thanks, but you are again contradicting yourself, because you closed this as completed 5 days ago and previously you wrote this here: #1866 (comment)

Release chain (expected timeline):

Eclipse 4.40 release (~mid-June 2026)

JDT-LS picks up new JDT jars (target tracks 4.40-I-builds)

vscode-java bumps the bundled JDT-LS server jar

End users update their vscode-java extension

This issue will stay open until step 4 is verified. If anyone hits a fat-jar shape that is not junit-platform-console-standalone-*.jar and still misdispatches to the JUnit 6 runner after upgrading, please post the project setup here — we'll revisit a downstream check at that point.

You said, this issue would stay open until the upstream fix is completed, merged into vscode-java and end-users updated vscode-java, so it should work. Given that you did close the issue already, I assumed that already happened, but you just said it did not. That's where my confusion came from.

You’re right that the status was confusing.

To clarify: this issue covered the vscode-java-test side, and that part is fixed: the new Enable Java Tests flow no longer installs the stale version, JUnit 5/6 are split, and the ASM startup issue is fixed.

The remaining failure with existing junit-platform-console-standalone-1.13.x projects is the same end-to-end issue tracked in redhat-developer/vscode-java#4396. The required JDT fix exists upstream, but it still needs to be included in JDT-LS and then shipped by redhat.java.

So for existing projects that must keep the 1.13.x jar, the current safe option is still to stay on redhat.java 1.53 until #4396 is resolved. Replacing the jar with JUnit Jupiter 6 is only a workaround.

David Thompson (@datho7561)

until #4396 is resolved

Wait, but over there, you wrote:

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

...and...

Closing this issue since the original Cannot find Testable (@testable) part is fixed, and the new CancellationToken symptom is tracked upstream at eclipse-jdt/eclipse.jdt.ui#2959.

(although you never actually closed it, even though said "closing this issue".)

So, is redhat-developer/vscode-java#4396 considered fixed or not...?

Plus, the eclipse-jdt issue you linked was closed already in April!

To avoid mixing several fixed and pending parts in this thread, I opened a dedicated tracking issue for the remaining end-to-end case: #1873.

This issue stays closed for the vscode-java-test fixes. The new tracking issue covers the remaining release-chain step: JDT-LS / redhat.java shipping the upstream JDT fix needed for existing junit-platform-console-standalone-1.13.x projects.

Navigation Menu

Repository navigation

Test Runner for Java Extension downloads old JUnit standalone #1866

Suggestions

References

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Test Runner for Java Extension downloads old JUnit standalone #1866

Description

Activity

github-actions commented on May 28, 2026

Suggestions

References

joaocaram commented on May 28, 2026

wenytang-ms commented on Jun 2, 2026

CherryDT commented on Jun 2, 2026

wenytang-ms commented on Jun 2, 2026

1 remaining item

joaocaram commented on Jun 4, 2026

CherryDT commented on Jun 4, 2026

wenytang-ms commented on Jun 8, 2026

wenytang-ms commented on Jun 9, 2026

CherryDT commented on Jun 9, 2026

wenytang-ms commented on Jun 9, 2026

CherryDT commented on Jun 9, 2026

wenytang-ms commented on Jun 9, 2026

CherryDT commented on Jun 9, 2026

wenytang-ms commented on Jun 9, 2026

CherryDT commented on Jun 9, 2026

wenytang-ms commented on Jun 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions