Language Support for Java(TM) by Red Hat causes Cursor to hang

[Denis_O_Sullivan]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have a Maven Java Project imported into Cursor.
When I enable Language Support for Java™ by Red Hat v1.53.0 extension it’s hanging.
The terminal shows
27263f07 Importing Maven project(s) - 22%

The java log shows the output below.
It was initially working but somewhere along the line it’s gotten into this state. I have performed the following steps multiple times.

Cleaned the Java Language Server Workspace via the IDE
Manually deleted the workspaceStorage and globalStorage.
Uninstalled and reinstalled Cursor.

If I create a new workspace and do a clean checkout of the project and import it. It will sometimes work for a day or 2 and then go back to the hanging state.

!SESSION 2026-03-16 11:11:57.915 -----------------------------------------------
eclipse.buildId=unknown
java.version=21.0.10
java.vendor=Eclipse Adoptium
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_IE
Framework arguments: --pipe=\.\pipe\lsp-fdfe7cf9a96cc78b2a50692631555441-sock
Command-line arguments: -data c:\Users\osuden02\AppData\Roaming\Cursor\User\workspaceStorage\f79fba7225465ccbd24045bc8da757b9\redhat.java\jdt_ws --pipe=\.\pipe\lsp-fdfe7cf9a96cc78b2a50692631555441-sock

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:22.910
!MESSAGE class org.eclipse.jdt.ls.core.internal.JavaLanguageServerPlugin is started

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.436
!MESSAGE Started org.eclipse.buildship.core 33ms

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.437
!MESSAGE Started org.eclipse.m2e.core 1ms

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.440
!MESSAGE ProjectRegistryRefreshJob finished 1ms

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.629
!MESSAGE Main thread is waiting

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.680
!MESSAGE >> initialize

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.684
!MESSAGE Initializing JDT Language Server (Standard)
- Version: 1.57.0-SNAPSHOT (OSGi 1.57.0.202602250925)
- Git Commit: 3a4b733 - Changelog for 1.57.0

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.726
!MESSAGE Static Commands:

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.727
!MESSAGE Non-Static Commands: [java.project.import, java.project.changeImportedProjects, java.navigate.openTypeHierarchy, java.project.resolveStackTraceLocation, java.edit.handlePasteEvent, java.edit.stringFormatting, java.project.getSettings, java.project.resolveWorkspaceSymbol, java.project.upgradeGradle, java.project.createModuleInfo, java.vm.getAllInstalls, java.edit.organizeImports, java.project.refreshDiagnostics, java.project.removeFromSourcePath, java.project.listSourcePaths, java.project.updateSettings, java.project.getAll, java.reloadBundles, java.project.isTestFile, java.project.resolveText, java.project.getClasspaths, java.navigate.resolveTypeHierarchy, java.getTroubleshootingInfo, java.edit.smartSemicolonDetection, java.project.updateSourceAttachment, java.project.updateClassPaths, java.decompile, java.protobuf.generateSources, java.project.resolveSourceAttachment, java.project.updateJdk, java.project.addToSourcePath, java.completion.onDidSelect]

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.729
!MESSAGE Static Commands:

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.730
!MESSAGE Non-Static Commands: [java.gradle.delegateTest]

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.731
!MESSAGE Static Commands:

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.733
!MESSAGE Non-Static Commands: [vscode.java.checkProjectSettings, vscode.java.isOnClasspath, vscode.java.fetchUsageData, vscode.java.validateLaunchConfig, vscode.java.resolveInlineVariables, vscode.java.resolveClassFilters, vscode.java.resolveMainMethod, vscode.java.resolveClasspath, vscode.java.resolveBuildFiles, vscode.java.resolveMainClass, vscode.java.updateDebugSettings, vscode.java.resolveSourceUri, vscode.java.fetchPlatformSettings, vscode.java.buildWorkspace, vscode.java.startDebugSession, vscode.java.inferLaunchCommandLength, vscode.java.resolveElementAtSelection, vscode.java.resolveJavaExecutable]

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.735
!MESSAGE Static Commands:

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.736
!MESSAGE Non-Static Commands: [java.project.refreshLib, java.project.checkImportStatus, java.project.list, java.project.generateJar, java.project.getMainClasses, java.project.getImportClassContent, java.getPackageData, java.project.getDependencies, java.resolvePath]

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.738
!MESSAGE Static Commands:

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.739
!MESSAGE Non-Static Commands: [java.maven.initializeSearcher, java.maven.searchArtifact, java.maven.addDependency, java.maven.controlContext]

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.771
!MESSAGE RepositoryRegistryUpdateJob finished 1ms

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.794
!MESSAGE >> initialized

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:33.819
!MESSAGE Importers: GradleBuildServerProjectImporter, GradleProjectImporter, MavenProjectImporter, EclipseProjectImporter, InvisibleProjectImporter

!ENTRY org.eclipse.jdt.ls.core 1 0 2026-03-16 11:12:34.311
!MESSAGE Importing Maven project(s)

Steps to Reproduce

Import a Maven Java Project and enable the Language Support for Java™ by Red Hat plugin. There is nothing else in particular that I’m doing

Expected Behavior

I should be able to have a Java Project that I can Run from within the IDE

Operating System

Windows 10/11

Version Information

Version: 2.6.19 (user setup)
VSCode Version: 1.105.1
Commit: 224838f96445be37e3db643a163a817c15b36060
Date: 2026-03-12T04:07:27.435Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

Yes - Cursor is unusable

[mohitjain (Mohit)]

Hi Denis,

The Java Language Server (JDT LS) bundled with the Red Hat extension is the same engine used in VS Code, so Maven import hangs like this are fairly well documented. That said, Cursor runs its own indexing alongside the extension, which can add some resource contention. The fact that a fresh checkout works for a day or two before failing again suggests workspace metadata or cache corruption building up over time.

Since you’ve already tried the usual workspace cleanups, a few additional things to check:

1. Inspect the process during the hang
When the import stalls at 22%, open Task Manager and check the java.exe process.

• If CPU is maxed out, the language server may be hitting a memory limit.

• If it’s mostly idle, it may be waiting on a Maven download or stuck in a deadlock.

2. Increase JDT LS memory
The language server heap may be too small for a large Maven project. In Cursor Settings (Ctrl + ,), set java.jdt.ls.vmargs to:

-XX:+UseParallelGC
-XX:GCTimeRatio=4
-XX:AdaptiveSizePolicyWeight=90
-Dsun.zip.disableMemoryMapping=true
-Xmx4G
-Xms512m

The default is often ~1 GB, which can be insufficient for bigger projects.

3. Clean the local Maven repository
Corrupted artifacts in ~/.m2 persist across Cursor reinstalls and workspace resets. Try deleting:

C:\Users\<your-username>\.m2\repository

or run:

mvn dependency:purge-local-repository

to force Maven to re-download dependencies.

4. Reduce import scope
In Cursor Settings:

• java.import.exclusions: add **/node_modules/**, **/target/**, **/.git/**

• java.autobuild.enabled: false

• java.import.maven.offline.enabled: true (if dependencies are already downloaded)

5. Verify the project builds outside Cursor
Run:

mvn clean install -U

If this also hangs or fails, the issue is likely in the Maven project itself rather than the language server.

6. Try the same project in VS Code
Open the project in VS Code with the same Red Hat Java extension.

• If it also hangs at 22%, it’s likely an extension or project-level issue.

• If it works there, that points to a Cursor-specific interaction we should investigate.

One additional note: your logs show JDT LS 1.57.0-SNAPSHOT, which is a pre-release build. If the steps above don’t help, it may be worth downgrading to the latest stable extension to rule out a regression.

If the issue persists, could you share the full Java Language Server log? You can open it via Ctrl+Shift+P → “Java: Open Java Language Server Log File.” That should help pinpoint where the import is getting stuck.

Best,
Mohit