You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Quarkus - java.lang.RuntimeException: Internal error. The test class SOMECLASS should have been loaded with a QuarkusClassLoader, but instead... #1602
%TESTC 4 v2
%TSTTREE2,ch.elexis.core.tasks.test.TaskServiceTest,true,4,false,1,TaskServiceTest,,[engine:junit-jupiter]/[class:ch.elexis.core.tasks.test.TaskServiceTest]
%TSTTREE3,runnableExecutionContext(ch.elexis.core.tasks.test.TaskServiceTest),false,1,false,2,runnableExecutionContext(),,[engine:junit-jupiter]/[class:ch.elexis.core.tasks.test.TaskServiceTest]/[method:runnableExecutionContext()]
%TSTTREE4,triggerCron(ch.elexis.core.tasks.test.TaskServiceTest),false,1,false,2,triggerCron(),,[engine:junit-jupiter]/[class:ch.elexis.core.tasks.test.TaskServiceTest]/[method:triggerCron()]
%TSTTREE5,reloadOnTaskDescriptorChangeDeleted(ch.elexis.core.tasks.test.TaskServiceTest),false,1,false,2,reloadOnTaskDescriptorChangeDeleted(),,[engine:junit-jupiter]/[class:ch.elexis.core.tasks.test.TaskServiceTest]/[method:reloadOnTaskDescriptorChangeDeleted()]
%TSTTREE6,completedWarnWithManualResolution(ch.elexis.core.tasks.test.TaskServiceTest),false,1,false,2,completedWarnWithManualResolution(),,[engine:junit-jupiter]/[class:ch.elexis.core.tasks.test.TaskServiceTest]/[method:completedWarnWithManualResolution()]
%ERROR 2,ch.elexis.core.tasks.test.TaskServiceTest
%TRACES
java.lang.RuntimeException: Internal error. The test class class ch.elexis.core.tasks.test.TaskServiceTest should have been loaded with a QuarkusClassLoader, but instead it was loaded with jdk.internal.loader.ClassLoaders$AppClassLoader@2c854dc5. This is caused by the FacadeClassLoader not correctly identifying this class as a QuarkusTest.
at io.quarkus.test.junit.QuarkusTestExtension.getClassLoaderFromTestClass(QuarkusTestExtension.java:334)
at io.quarkus.test.junit.QuarkusTestExtension.ensureStarted(QuarkusTestExtension.java:610)
at io.quarkus.test.junit.QuarkusTestExtension.beforeAll(QuarkusTestExtension.java:687)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
%TRACEE
%RUNTIME57
while running a test on the classes test method works (tested clicking on #runnableExecutionContext()) with result
Hi Marco Descher (@col-panic), 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.
Workaround & Suggestions
Run the test class through Maven/Surefire instead of the VS Code Test Explorer, which will correctly wire up the QuarkusClassLoader:
mvn test -Dtest=TaskServiceTest
In VS Code you can click the ▶️ icon on individual test methods (#runnableExecutionContext(), etc.)—these correctly start under the QuarkusClassLoader.
Track and subscribe to the upstream issue where class‐level runs aren’t recognized as QuarkusTests:
Other references with low confidence
- **Error messages append out of the method when it happens at lifecycle methods** – deals with stack-trace placement, not class-loading for QuarkusTests. https://github.com/microsoft/vscode-java-test/issues/1392
- **When running debug, test dependencies are not included but test codes are.** – about missing test classpath entries under debug, not QuarkusClassLoader. https://github.com//issues/1326
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!
This isn't a bug in vscode-java-debug/vscode-java-test — it's a class-loading issue in the Eclipse JDT JUnit 5 runtime used to launch JUnit 5 tests (the %TESTC/%TSTTREE output is from JDT's RemoteTestRunner).
Quarkus requires @QuarkusTest classes to be loaded by its QuarkusClassLoader via a FacadeClassLoader installed during discovery. Older JDT loaded the two paths asymmetrically:
Method run -> selectMethod(clazz.getName()+"#"+name) (string) -> goes through the facade ✅
Class run -> selectClass(clazz) (already-loaded Class) -> bypasses the facade ❌
Already fixed upstream in Eclipse JDT commit 6e94b0f3 (2025-06-05):
Fix: update Language Support for Java(TM) (redhat.java) to a build bundling JDT from June 2025 or later. Workaround: run individual methods, or mvn test -Dtest=TaskServiceTest.
Update — this fix is already released, so it should be a matter of updating your extension:
The JDT fix merged 2025-06-06; eclipse.jdt.ls started bundling it via the 4.37 (2025-09) Eclipse stream from ~2025-06-10.
It has been shipping in Language Support for Java(TM) (redhat.java) since roughly v1.43/v1.44 (mid-2025) and is present in all current versions (latest v1.50.0).
Please update redhat.java to the latest version (and make sure the Quarkus extension pack pulls the updated redhat.java with it); class-level @QuarkusTest runs should then work.
If you are already on the latest redhat.java and still hit this, that would be a separate regression — please open an issue on https://github.com/redhat-developer/vscode-java with your redhat.java and JDT LS versions.
Activity
github-actions commentedon Jan 12, 2026
Hi Marco Descher (@col-panic), 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.
Workaround & Suggestions
Run the test class through Maven/Surefire instead of the VS Code Test Explorer, which will correctly wire up the QuarkusClassLoader:
mvn test -Dtest=TaskServiceTestIn VS Code you can click the▶️ icon on individual test methods (
#runnableExecutionContext(), etc.)—these correctly start under the QuarkusClassLoader.Track and subscribe to the upstream issue where class‐level runs aren’t recognized as QuarkusTests:
Other references with low confidence
- **Error messages append out of the method when it happens at lifecycle methods** – deals with stack-trace placement, not class-loading for QuarkusTests. https://github.com/microsoft/vscode-java-test/issues/1392 - **When running debug, test dependencies are not included but test codes are.** – about missing test classpath entries under debug, not QuarkusClassLoader. https://github.com//issues/1326The 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 commentedon Jun 2, 2026
This isn't a bug in
vscode-java-debug/vscode-java-test— it's a class-loading issue in the Eclipse JDT JUnit 5 runtime used to launch JUnit 5 tests (the%TESTC/%TSTTREEoutput is from JDT'sRemoteTestRunner).Quarkus requires
@QuarkusTestclasses to be loaded by itsQuarkusClassLoadervia aFacadeClassLoaderinstalled during discovery. Older JDT loaded the two paths asymmetrically:selectMethod(clazz.getName()+"#"+name)(string) -> goes through the facade ✅selectClass(clazz)(already-loadedClass) -> bypasses the facade ❌Already fixed upstream in Eclipse JDT commit
6e94b0f3(2025-06-05):Fix: update Language Support for Java(TM) (redhat.java) to a build bundling JDT from June 2025 or later.
Workaround: run individual methods, or
mvn test -Dtest=TaskServiceTest.wenytang-ms commentedon Jun 2, 2026
Update — this fix is already released, so it should be a matter of updating your extension:
eclipse.jdt.lsstarted bundling it via the 4.37 (2025-09) Eclipse stream from ~2025-06-10.Please update
redhat.javato the latest version (and make sure the Quarkus extension pack pulls the updatedredhat.javawith it); class-level@QuarkusTestruns should then work.If you are already on the latest
redhat.javaand still hit this, that would be a separate regression — please open an issue on https://github.com/redhat-developer/vscode-java with yourredhat.javaand JDT LS versions.wenytang-ms commentedon Jun 8, 2026
close this issue since fixed, please feel free to reopen this issue once you meet again!