# vscode-java: Eclipse JDT behind a Visual Studio Code extension

> Red Hat's Java extension for VS Code, built on the Eclipse JDT language server. Two JDK versions to think about, a package version ahead of the last release, and 940 open issues.

**redhat-developer/vscode-java** — Java Language Support for Visual Studio Code

- Repository: https://github.com/redhat-developer/vscode-java
- Stars: 2,308 · Forks: 550
- Language: TypeScript
- License: EPL-2.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/redhat-developer-vscode-java

## JDT, M2Eclipse and Buildship doing the work

The extension is a thin shell. The README states that Java language support comes via the Eclipse JDT Language Server, which in turn uses Eclipse JDT, M2Eclipse and Buildship. That stack is the whole story of what you get: the analysis engine, the Maven integration and the Gradle integration are all the Eclipse implementations, wrapped in a Visual Studio Code extension written in TypeScript.

GitHub reports TypeScript as the language, an EPL-2.0 license, 2,301 stars, 549 forks and 940 open issues, with the last push on 2026-09-28. The repository tree confirms the shape: `src/` for the extension, `language-support/` for the code that talks to the server, `formatters/`, `lombok/`, `snippets/`, `schemas/`, `webview-resources/`, `test/` and a `webpack.config.js` for the build. There is also a `USAGE_DATA.md`, which is worth reading before you deploy this in an environment with telemetry requirements.

The 940 open issues figure deserves context rather than alarm. This is an extension that has shipped continuously for years and absorbs feature requests for an entire language server through a single tracker. Compare it against the ratio for a small library and it is not alarming; compare it against the number of people who use it daily and it is a support burden.

## Two different JDKs, and the confusion that causes

The README separates the JDK that runs the language server from the JDK that compiles your project, and the distinction is the first thing to get right.

The Java Tooling JDK launches the language server. Since the extension began publishing platform specific versions, it embeds a JRE for `win32-x64`, `win32-arm64`, `linux-x64`, `linux-arm64`, `darwin-x64` and `darwin-arm64`, so on those platforms the extension activates with no setup at all. The JDK configuration section survives only for the universal version, where the tooling JDK has a minimum of Java 25 and is located through the `java.jdt.ls.java.home` setting or, failing that, the `JDK_HOME` environment variable, the `JAVA_HOME` environment variable, and finally the system path.

Project JDKs are separate and are yours to configure. The README recommends the `java.configuration.runtimes` property in user settings, with a list of named runtimes where one is marked as the default:

```json
"java.configuration.runtimes": [
  {
    "name": "JavaSE-1.8",
    "path": "/path/to/jdk-8",
  },
  {
    "name": "JavaSE-11",
    "path": "/path/to/jdk-11",
  },
  {
    "name": "JavaSE-25",
    "path": "/path/to/jdk-25",
    "default": true
  }
]
```

The default runtime is used when you open standalone Java files, which is the case where no build file tells the server what to do. Feature support runs from Java 1.8 to Java 27, and a project JDK of Java 1.8 or above is supported.

## Project detection and what activates the extension

The quick start says the extension activates when you first access a Java file, and it recognises projects by Maven or Gradle build files in the directory hierarchy. The activation events in the manifest are more precise than that: the extension activates on `workspaceContains` for `pom.xml`, `build.gradle`, `settings.gradle`, `build.gradle.kts`, `settings.gradle.kts` and `.classpath`, each with a wildcard variant for nested locations, plus two command activations for template variables and metadata file generation.

So a folder with a `pom.xml` two levels down is enough. That is convenient for monorepos and it also means the extension will wake up in directories you did not expect, which is the mechanism behind a common class of complaints about memory use in large workspaces.

The manifest also declares limited support for untrusted workspaces, with six settings treated as restricted: `java.jdt.ls.java.home`, `java.home`, `java.jdt.ls.vmargs`, `java.configuration.runtimes`, `java.import.gradle.java.home` and `java.import.gradle.home`. The list is effectively a map of every setting that can point the extension at code it would execute, and it is the right thing to check if you open untrusted repositories.

The minimum VS Code version is `^1.77.0`, and virtual workspaces are not supported at all, which rules out github.dev style editing for Java.

## The feature list, and the commands that fix things

The README's feature list is long enough to be worth quoting by category rather than in full. Analysis features include as-you-type reporting of parsing and compilation errors, code completion, type search, highlights and diagnostic tags. Navigation includes code outline, code folding, code lens for references and implementations, call hierarchy, type hierarchy, inlay hints and semantic selection. Editing includes code and source actions, refactoring, javadoc hovers, organize imports, code formatting, code snippets and annotation processing support, automatic for Maven projects.

The commands list is where the real difference from a lightweight editor shows. `Java: Reload Projects` (`Shift+Alt+U`) forces project configuration and classpath updates after a dependency change or compilation level change. `Java: Force Java Compilation` (`Shift+Alt+B`) triggers compilation of the workspace by hand. `Java: Rebuild Projects` does a full build of the selected projects. `Java: Clean Java Language Server Workspace` resets the server's workspace state.

There are also three log commands, for the language server log, the extension log, and both at once, which is the single most useful thing to attach to a bug report. And a set of source-path commands: `Java: Add Folder to Java Source Path`, `Java: Remove Folder from Java Source Path` and `Java: List All Java Source Paths`, the first two of which only work for unmanaged folders.

`Java: Switch to Standard Mode` deserves its own note. It is only available when the language server is in LightWeight mode, which is the state the server starts in for files that are not part of an imported project. So a plain Java file opened on its own gets a faster, less capable analysis until you switch.

## Release cadence and a manifest version ahead of the last tag

The releases are versioned 1.x with dates roughly a quarter apart: 1.54.0 on 2026-04-15, 1.55.0 on 2026-06-25 and 1.56.0 on 2026-09-02. That cadence matters for a language extension, since every release bundles a newer language server.

The 1.56.0 notes are a good sample of what an update contains, and none of it is headline-grabbing: a setting for the Maven project cache size, a setting for Eclipse classpath variables of kind var, a `projectOnly` scope for the `java.search.scope` setting to exclude JDK and library references, Javadoc generation as Markdown, auto-inserting a space after keyword autocompletion, hiding context menu items when right clicking folders that are not Java projects, and a CodeLens on fields showing references.

That last entry, a setting to make new classes package-private rather than public, is the kind of change that tells you who this extension is for. It is responding to people who write Java in a style, and the people filing these requests are often coming from Eclipse habits.

There is one number to reconcile if you check the repository yourself. The manifest in the repository declares version 1.57.0, while the newest published release is 1.56.0. Both facts sit in the repository: `main` carries the in-development version and the last tag is one behind. Install from the Marketplace rather than building from `main`, or you will be running an unreleased build.

## How this compares with IntelliJ for Java

The honest comparison is that vscode-java gets you Eclipse's analysis in a lighter host, and loses on the things an IDE invests in that a language server extension does not. IntelliJ has refactorings with preview and undo, a much deeper Maven and Gradle integration including profiles and dependency management UI, a dataflow analyzer for method calls, and built-in profiling and profiling views. It also has a Java debugger integrated with the editor rather than installed separately.

That last point is in the README itself. To launch and debug Java programs, the recommendation is to install the Java Debug Extension for Visual Studio Code as a separate extension. That is not a complaint about the architecture, it is how the extension ecosystem splits concerns, but it does mean a working edit-debug-run loop needs at least two extensions.

Where vscode-java wins is the rest of your workflow. If your Java lives next to TypeScript, Python or Go in the same repository, one editor means one set of keybindings, one theme, one search across all files, and one set of extensions. For a polyglot monorepo that argument is usually decisive.

The README points to a changelog file and a project wiki for anything beyond the basics, and those are the places to look before deciding. The README covers installation, JDK configuration, the command list and the feature list; everything about configuring individual Maven or Gradle behaviour lives in the wiki and in the settings themselves.

## Conclusion

The practical case for this extension is not that it beats IntelliJ IDEA at Java, it is that it puts real JDT analysis inside an editor people already use for everything else. That means Maven and Gradle import, refactoring and type hierarchy work the way Eclipse users expect, without a second IDE. The costs are the ones you would expect from an Eclipse codebase running in a TypeScript host: a full build step for classpath updates, a lag between opening a build file and seeing diagnostics, and a large issue backlog. Configure `java.configuration.runtimes` before you open anything, keep the embedded JRE for the language server and a project JDK for compilation, and read the changelog when you upgrade since releases land roughly every quarter.

## FAQ

### Can I do Java in VS Code?

Yes. Red Hat publishes the java extension for the Visual Studio Marketplace, and it activates on its own when you open a Java file or when the workspace contains a pom.xml, build.gradle, settings.gradle or .classpath. The analysis comes from the Eclipse JDT language server, so Maven and Gradle projects are imported rather than merely parsed.

### Which is better, VS Code or IntelliJ for Java?

IntelliJ IDEA goes deeper on Java-specific work: richer refactorings, Maven and Gradle dependency management UI, dataflow analysis, and an integrated debugger. vscode-java wins when your repository is polyglot, because one editor covers the other languages too. It also gets Eclipse's JDT engine, which many Java developers already trust.

### Which IDE is best for Java?

For pure Java work, IntelliJ IDEA remains the most capable option. Eclipse is the traditional alternative and shares an engine with this extension, so if you are migrating from Eclipse the analysis behaviour will feel familiar in VS Code. The practical choice is usually about what else you edit in the same repository rather than about Java itself.

### Is VS Code a good IDE for Java?

It is a good editor for Java, though calling it an IDE oversells it. The Eclipse JDT language server gives you completion, diagnostics, refactoring, call hierarchy and Maven or Gradle import, so the core experience is close to Eclipse. What you give up against IntelliJ IDEA is deeper refactoring tooling, dependency management UI and dataflow analysis, and debugging needs a separate extension.

## Sources

- [Issues](https://github.com/redhat-developer/vscode-java/issues)
- [License: EPL-2.0](https://github.com/redhat-developer/vscode-java/blob/main/LICENSE)
- [README](https://github.com/redhat-developer/vscode-java/blob/main/README.md)
- [redhat-developer/vscode-java on GitHub](https://github.com/redhat-developer/vscode-java)
- [Releases](https://github.com/redhat-developer/vscode-java/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/redhat-developer-vscode-java