LSP server stuck in starting status
Describe the bug LSP server is stuck in starting status and doesn't make progress.
To Reproduce Just open a Java file with lsp-java mode enabled.
GNU Emacs 27.2
Copyright (C) 2021 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
macOS BigSur Version 11.5.2
Expected behavior LSP server start normally.
Screenshots

Logs *lsp-log* has following error:
Aug 23, 2021, 11:20:51 PM While loading class "org.eclipse.buildship.core.internal.util.gradle.PublishedGradleVersions", thread "Thread[Worker-0: Loading available Gradle versions,5,main]" timed out waiting (30040ms) for thread "Thread[pool-2-thread-1,5,main]" to finish starting bundle "org.eclipse.buildship.core_3.1.5.v20210112-1646-s [14]". To avoid deadlock, thread "Thread[Worker-0: Loading available Gradle versions,5,main]" is proceeding but "org.eclipse.buildship.core.internal.util.gradle.PublishedGradleVersions" may not be fully initialized.
Unable to acquire the state change lock for the module: osgi.identity; type="osgi.bundle"; version:Version="3.1.5.v20210112-1646-s"; osgi.identity="org.eclipse.buildship.core"; singleton:="true" [id=14] STARTED [STARTED]
org.osgi.framework.BundleException: Unable to acquire the state change lock for the module: osgi.identity; type="osgi.bundle"; version:Version="3.1.5.v20210112-1646-s"; osgi.identity="org.eclipse.buildship.core"; singleton:="true" [id=14] STARTED [STARTED]
at org.eclipse.osgi.container.Module.lockStateChange(Module.java:350)
at org.eclipse.osgi.container.Module.start(Module.java:419)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:506)
at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:117)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:572)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:346)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:401)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:480)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:171)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at org.eclipse.buildship.core.internal.util.gradle.PublishedGradleVersionsWrapper$LoadVersionsJob.run(PublishedGradleVersionsWrapper.java:60)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.util.concurrent.TimeoutException: Timeout after waiting 30 seconds to acquire the lock.
at org.eclipse.osgi.container.Module.lockStateChange(Module.java:347)
... 11 more
Caused by: org.eclipse.osgi.framework.util.ThreadInfoReport: Thread dump
After deleting ~/.emacs.d/.cache/lsp/eclipse.jdt.ls/plugins/org.eclipse.buildship.core_3.1.5.v20210112-1646-s.jar, LSP server starts as usual.
BTW, I don't need gradle support.
I think there is problem when Gradle didn't exit properly.
So after kill gradle process and delete files .fileTableLock in path of jdtls path,
it starts for me.
I'm using lsp-java with:
- Emacs 29
- Debian 12
- Java 21.0.1
I'm experiencing the same TimeoutException issue when I restart emacs and open a Java file in my project. However, removing the .fileTableLock doesn't fix the problem.
The only way I've found to get LSP running again is to remove the ~/.emacs.d/.cache/lsp/eclipse.jdt.ls folder before staring emacs.
Another way around the problem is to use lsp-install-server and then lsp-workspace-restart. Note, that I get a deprecation warning about using lsp-java-update-server.
If I remove ~/.emacs.d/.cache/lsp/eclipse.jdt.ls/plugins/org.eclipse.buildship.core_3.1.x.xxxxxxxx.jar and restart emacs, lsp just hangs.