bug: Cannot invoke "org.eclipse.jdt.core.search.SearchPattern.findIndexMatches .... because "pattern" is null

[ahakanbaba]

Did you check docs and existing issues?

• I have read all the plugin docs
• I have searched the existing issues
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.11.1 Build type: Release LuaJIT 2.1.1741730670

Operating system/version

22.04.1-Ubuntu

Describe the bug

I have added this remote debug configuration

    dap.configurations.java = {
        {
            mainClass = '',
            projectName = '',
            name     = "Attach to Gradle bootRun";
            type     = "java";
            request  = "attach";

            -- These two fields are re-used by the adapter definition above:
            hostName = "127.0.0.1";
            port     = 5005;
        },
    }

And running a gradle command with this

./gradlew :bootRun  --debug-jvm

When I try to DapContinue, I get this error

Error executing vim.schedule lua callback: ...e/nvim/lazy/nvim-java-core/lua/java-core/utils/async.lua:41: unhandled error RPC[Error] code_name = UnknownErrorCode, message = "Cannot invoke \"org.eclipse.jdt.core.se
arch.SearchPattern.findIndexMatches(org.eclipse.jdt.internal.core.index.Index, org.eclipse.jdt.internal.core.search.IndexQueryRequestor, org.eclipse.jdt.core.search.SearchParticipant, org.eclipse.jdt.core.search.IJ
avaSearchScope, org.eclipse.core.runtime.IProgressMonitor)\" because \"pattern\" is null" data = {
  message = 'Cannot invoke "org.eclipse.jdt.core.search.SearchPattern.findIndexMatches(org.eclipse.jdt.internal.core.index.Index, org.eclipse.jdt.internal.core.search.IndexQueryRequestor, org.eclipse.jdt.core.searc
h.SearchParticipant, org.eclipse.jdt.core.search.IJavaSearchScope, org.eclipse.core.runtime.IProgressMonitor)" because "pattern" is null'
}
stack traceback:
        [C]: in function 'error'
        ...e/nvim/lazy/nvim-java-core/lua/java-core/utils/async.lua:41: in function 'callback'
        ...nvim-java-core/lua/java-core/ls/clients/jdtls-client.lua:74: in function 'handler'
        /opt/nvim/share/nvim/runtime/lua/vim/lsp/client.lua:682: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

I am relatively new in this jvm development state so, I am not sure where to look at for some debugging. Any tip for help me understand one level detail about this problem would be very appreciated.

Steps To Reproduce

Unfortunately I was not able to reproduce this in a simple project.

With the same attach configuration in dap.configurations.java, I can attach to a simple java application that was started with something like

./gradlew  runJava --debug-jvm

In that java-tutorial simple project, I can successfullly
:DapToggleBreakpoint
and
:DapContinue

I select the attach configuration and stepping, printing all work.

However in a more complex project, I am getting this error.

Expected Behavior

To attach to the remote debugging port and step ...

[ahakanbaba]

Looking a little bit deeper, in the jdtls logs in the project workspace.
This is the path
~/.cache/nvim/jdtls/workspaces/<derived_dir_name_from_cwd>/.metadata/.log

I see this error

!ENTRY org.eclipse.jdt.ls.core 4 0 2025-05-15 16:05:35.241
!MESSAGE Error in calling delegate command handler
!STACK 0
java.lang.NullPointerException: Cannot invoke "org.eclipse.jdt.core.search.SearchPattern.findIndexMatches(org.eclipse.jdt.internal.core.index.Index, org.eclipse.jdt.internal.core.search.IndexQueryRequestor, org.eclipse.jdt.core.search.SearchParticipant, org.eclipse.jdt.core.search.IJavaSearchScope, org.eclipse.core.runtime.IProgressMonitor)" because "pattern" is null
	at org.eclipse.jdt.internal.core.search.matching.MatchLocator.findIndexMatches(MatchLocator.java:309)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.search(PatternSearchJob.java:237)
	at org.eclipse.jdt.internal.core.search.PatternSearchJob.execute(PatternSearchJob.java:118)
	at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:383)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:260)
	at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:620)
	at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:677)
	at com.microsoft.java.debug.plugin.internal.ResolveClasspathsHandler.getJavaProjectFromType(ResolveClasspathsHandler.java:146)
	at com.microsoft.java.debug.plugin.internal.ResolveClasspathsHandler.computeClassPath(ResolveClasspathsHandler.java:188)
	at com.microsoft.java.debug.plugin.internal.ResolveClasspathsHandler.computeClassPath(ResolveClasspathsHandler.java:165)
	at com.microsoft.java.debug.plugin.internal.ResolveClasspathsHandler.resolveClasspaths(ResolveClasspathsHandler.java:76)
	at com.microsoft.java.debug.plugin.internal.JavaDebugDelegateCommandHandler.executeCommand(JavaDebugDelegateCommandHandler.java:62)
	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:610)
	at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
	at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

So maybe this is an error at the jdtls level ?
Maybe some message goes in an unexpected status to jdtls ?
Any pointers to get some more observability to the jdtls interactions ?

Needless to say, I can connect to this port and step and debug with IntelliJ