Fixing the 'Language Support for Java' Server Crash in VS Code

When Java IntelliSense Stops WorkingFew things stall a productive coding session faster than losing your IDE's "brain." You're in the middle of a refactor, and suddenly, the red squiggles vanish, autocomplete stops responding, and a persistent notification appears at the bottom right:

The Language Support for Java server crashed 5 times in the last 3 minutes. The server will not be restarted.

This error means the Eclipse JDT.LS engine—the backend powering the extension—has hit a fatal wall. Without it, VS Code is just a basic text editor. To fix it, we need to look beyond the generic popup and address the underlying configuration or cache issues.

Step 1: Don't Guess, Check the LogsBefore changing settings, find out exactly why the server gave up. The logs usually reveal if you're dealing with a memory leak or a version mismatch.

• Open the Output panel in VS Code (View > Output).- Select Language Support for Java from the dropdown menu on the right.- Look for stack traces. Specific errors like java.lang.OutOfMemoryError or UnsupportedClassVersionError will tell you exactly which solution to prioritize.## Solution 1: Clean the Language Server WorkspaceThe extension keeps an index of your project to keep things fast. If this index gets corrupted—perhaps from an abrupt system shutdown—the server will crash every time it tries to read the broken files. This is the most common fix.
• Press Ctrl+Shift+P (or Cmd+Shift+P on macOS).- Search for "Java: Clean Java Language Server Workspace".- Click Restart and Delete when prompted.VS Code will wipe its internal cache and re-index your files. For small to medium projects, this usually takes less than 30 seconds and fixes the majority of persistent crashes.

Solution 2: Align Your Runtime JDKConfusion often arises here: the JDK you use to build your project is different from the JDK used to run the VS Code extension. Since version 1.0.0, the Red Hat extension requires JDK 17 or higher to operate. If you're trying to run the tool on JDK 11, it will crash immediately.

Check your settings.json to ensure java.jdt.ls.java.home points to a modern runtime:

{
  "java.jdt.ls.java.home": "/usr/lib/jvm/java-17-openjdk",
  "java.configuration.runtimes": [
    {
      "name": "JavaSE-1.8",
      "path": "/path/to/old-jdk-8",
      "default": true
    }
  ]
}

In this setup, your project still compiles with Java 8, but the IDE tools remain stable on Java 17.

Solution 3: Feed the Server More MemoryIf you're working on a massive multi-module Maven project (think 50+ modules or thousands of classes), the default 1GB of memory isn't enough. When the server hits its limit, it triggers an OutOfMemoryError and dies.

• Open Settings (Ctrl+,) and search for java.jdt.ls.vmargs.- Locate the -Xmx parameter.- Increase it to -Xmx2G or -Xmx4G.A typical high-performance setting looks like this:

"java.jdt.ls.vmargs": "-XX:+UseG1GC -XX:+UseStringDeduplication -Xmx2G -Xms1G"

Solution 4: The Manual Cache PurgeSometimes the "Clean Workspace" command won't run because the extension is too broken to respond. In these cases, you have to delete the storage folder manually while VS Code is closed.

Navigate to these paths and delete the workspaceStorage folder:

• Windows: %APPDATA%\Code\User\workspaceStorage- macOS: ~/Library/Application Support/Code/User/workspaceStorage- Linux: ~/.config/Code/User/workspaceStorageDon't worry about losing code; this folder only contains temporary indices and metadata. VS Code will rebuild everything automatically the next time you open your project.

Confirming the FixAfter restarting, watch the status bar. You should see a progress icon showing "Opening Java projects" followed by a "Ready" message. To be sure, try hitting F12 on a method—if it jumps to the definition instantly, you're back in business. If the server stays active for 10 minutes of heavy editing, the problem is solved.

Stability TipsTo avoid seeing this error again, keep your extensions updated. Red Hat releases stability patches monthly. Also, use a tool like SDKMAN! to manage your JDKs; it makes switching between the JDK 17 required by your tools and the older versions required by your legacy projects much simpler.