StackOverflowError in HierarchyResolver

[usrlocl]

I'm encountering StackOverflowError in HierarchyResolver when querying outgoingCalls in my workspace. I'm running JDTLS directly as part of my custom application and not in an editor. I have tried a minimal reproducer here:

https://github.com/usrlocl/jdtls-stackoverflow-reproduce

The workflow is as follows:

1. spawn jdtls with following params:

  '-Dosgi.bundles.defaultStartLevel=4',
  '-Declipse.product=org.eclipse.jdt.ls.core.product',
  '-Dlog.level=WARN',
  '-Xmx1G',
  '--add-modules=ALL-SYSTEM',
  '--add-opens', 'java.base/java.util=ALL-UNNAMED',
  '--add-opens', 'java.base/java.lang=ALL-UNNAMED',
  '-jar', <path-to-launcherJar>,
  '-configuration', <jdtls-path>/config_linux,
  '-data', <data-dir>

2. send following initialize request:
   workspace: https://github.com/usrlocl/jdtls-stackoverflow-reproduce/tree/master/fail (local path)
   options:

    rootUri: <workspace-uri>,
    workspaceFolders: [{ uri: <workspace-uri>, name: <workspace-name> }],
    capabilities: {
      documentSymbol: {
        hierarchicalDocumentSymbolSupport: true,
      },
      workspace: { workspaceFolders: true, configuration: true },
      textDocument: { callHierarchy: { dynamicRegistration: false } },
      window: {
        workDoneProgress: true,
      },
    },
    initializationOptions: {}

3. wait for serviceReady notification from jdtls
4. send didOpen for all source files in the workspace
5. send textDocument/prepareCallHierarchy at following position
   (https://github.com/usrlocl/jdtls-stackoverflow-reproduce/blob/master/fail/src/main/java/foo/Foo.java#L5)
6. send callHierarchy/outgoingCalls for returned items

This results in following stacktrace (recurses until StackOverflowError).

Target: method() : void (6) — src/main/java/foo/Foo.java:5:3
[jdtls] Aug 14, 2026 12:38:57 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint fallbackResponseError
SEVERE: Internal error: java.lang.StackOverflowError
java.util.concurrent.CompletionException: java.lang.StackOverflowError
	at java.base/java.util.concurrent.CompletableFuture.wrapInCompletionException(CompletableFuture.java:323)
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:359)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:364)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:670)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:504)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:511)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1450)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2019)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)
Caused by: java.lang.StackOverflowError
	at org.eclipse.jdt.internal.core.NameLookup.seekPackageFragments(NameLookup.java:1367)
	at org.eclipse.jdt.internal.core.NameLookup.seekPackageFragments(NameLookup.java:1241)
	at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:818)
	at org.eclipse.jdt.internal.core.NameLookup.findType(NameLookup.java:744)
	at org.eclipse.jdt.internal.core.SearchableEnvironment.find(SearchableEnvironment.java:200)
	at org.eclipse.jdt.internal.core.SearchableEnvironment.findType(SearchableEnvironment.java:575)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.fromSplitPackageOrOracle(LookupEnvironment.java:520)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.lambda$1(LookupEnvironment.java:384)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForTypeFromModules(LookupEnvironment.java:487)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:383)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:277)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:620)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:320)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:279)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment$CompleteTypeBindingsSteps.perform(LookupEnvironment.java:220)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:677)
	at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:213)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:434)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:277)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:620)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.resolveImports(CompilationUnitScope.java:320)
	at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:279)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment$CompleteTypeBindingsSteps.perform(LookupEnvironment.java:220)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:677)
	at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.accept(HierarchyResolver.java:213)

I'm not sure what causes this, but it does seem to be during some king of type lookup. Interestingly, I've found several ways in my sample code to circumvent this error. Changing any of the following fails to reproduce the error:

1. Removing module-info.java
2. Removing a self-referencing import from one of the source files
3. Using different package path for test sources from the main sources.
4. Not issuing didOpen to all the source files in workspace before querying outgoingCalls.

It seems to be some very particular code path that triggers this, and I've tried to narrow this down as much as possible in the reproducer.

I also tried my sample application directly in vscode using the Redhat Java extension following the same workflow (opening all the documents, waiting for indexing to complete etc.). I was unable to reproduce the error and vscode is able to query outgoingCalls successfully. I'm not sure if there's something different in the way the Java extension manages JDTLS or if there's something different in the way vscode integrates with the language server. I've played around with a few different settings

Is this a known issue in JDTLS? If so, any tips on how to circumvent it?

[datho7561]

I can reproduce the stack overflow in jdtls when I open the file; I think it's not necessarily in response to that particular request though? I think it might be the incremental builder (i.e. background compiler job)?

I have a vague memory of an upstream bug in JDT related to an import that imports something from the same file causing this. It's worth investigating further, with that as a starting point. The fix is probably upstream.

[usrlocl]

How exactly are you able to reproduce? I'm not able to any other way except for the very specific workflow that I described.

I'm also unable to reproduce it on an editor (vscode and eclipse), so wondering if there's a specific setting that can workaround this issue for now?

[datho7561]

I opened the logs in the dedicated mode in VS Code, searched for "Exception", and found it.

[usrlocl]

Strange, I checked both language server and java extension log files and don't see any.

I'm using vscode v1.108.1 with java extension v1.55.0 and all default settings