Making your life as a developer easier

New in Eclipse JDT language server

Fred Bricon
© Shutterstock / Sadovski

Have you heard about Eclipse JDT Language Server (a.k.a. In this article, Fred Bricon explains all the changes to this open source Java language specific implementation of the Language Server Protocol.

It’s been “almost” a year since our last article for the Eclipse Newsletter, and a lot has happened in the project since. In this article, we’ll cover some of the highlights of the past releases and the impact the project had on the Java ecosystem.

Improvements all over the place!

Over the past 10 months, received a fair share of bug fixes and some notable improvements, including, among other things:

  • smaller distribution size,
  • faster start times,
  • improved diagnostics performance,
  • new Java 9 and 10 support,
  • improvements to the “organize imports” refactoring (with favorite imports, imports order, execute on save),
  • code actions galore (known as quick-fixes in Eclipse IDE land),
  • the ability to disable autobuilds, or trigger incremental or full builds on demand,
  • proper test classpath isolation (i.e. test classes don’t leak into main code anymore),
  • improved symbol (a.k.a. Type) search,
  • new multi-root support,
  • partial rename refactoring support (still missing file rename)
  • support for 3rd party extensions (debugger, decompilers, new commands, notifications),
  • provided a progress report API, allowing clients to track background activity,
  • on-type formatting support, to automatically format your code after ending a line or a block,
  • support for Eclipse formatter settings
  • support for annotation processing

For some of those fixes and improvements, leverages the latest milestone developments from the Eclipse Photon SDK. integrated everywhere

While vscode-java is the reference implementation for clients, others have jumped on the train, like the ide-java extension for the Atom editor:

eclipse jdt language server 1

or YCMD, providing autocompletion in VIM:

A flourishing ecosystem

As we’re seeing being used more and more across the LSP client landscape, we’ve inevitably received many requests to allow 3rd party extensions to integrate deeply with

Because the server is based on the OSGi framework powering the Eclipse IDE, we could open the gates to allow external extensions, fairly easily. During the initialize request, clients must provide the bundlesparameter, which lists the full path of all OSGi bundles needed to be started by :

interface InitializationOptions {
         * a list of Java LS extensions
        bundles?: string[];
         * a list of workspace folders
        workspaceFolders?: WorkspaceFolder[];
         * Java LS configuration settings
        settings?: JavaConfigurationSettings[];

In order to contribute commands, bundles need to provide a extension point in their plugin.xml, with a list of command ids, like :

   <extension point="">
      <delegateCommandHandler class="">
            <command id=""/>
            <command id=""/>
            <command id=""/>
            <command id=""/>
            <command id=""/>
            <command id=""/>

This mechanism allowed the Microsoft team to implement a complete Java debugger extension for VS Code:

eclipse jdt language server 2

… and a Java Test runner

eclipse jdt language server 3


Eclipse Che, currently in the process of replacing its own Java language server with, should reach feature parity with its old server by providing custom extensions, for instance dependency visualization:

David Gileadi added support for external decompilers implementations by implementing the extension point. A VSCode extension is available, but the bundles can be embedded in any client.

Finally, Gorkem Ercan, fearless leader of the project, can satisfy his dogfooding needs by developing with in VS Code: his vscode-pde extension allows the development of Eclipse Plugins by loading a target platform file, referenced in a javaConfig.json file. The extension point allows 3rd party adopters to expand the types of projects imported by beyond simply Maven, Gradle and Eclipse projects.

What’s next?

The team tries to keep a 2-weeks release cadence, making each release incrementally superior to the last. We’re collaborating with the LSP4J and the Microsoft teams to keep improving the Language Server Protocol, so, in the near future, we’ll hopefully be able to provide :

  • full renaming support (including moving files),
  • expose message severity settings
  • more refactorings / code actions
  • squash more bugs

All contributions are welcome, so feel free to chime in the channel on Mattermost, or open bug reports (and submit pull requests!) to


This post was originally published in the March 2018 issue of the Eclipse Newsletter: Coding in Different Languages

For more information and articles check out the Eclipse Newsletter.


Fred Bricon

Fred Bricon is a code monkey at Red Hat, making hipsters use Eclipse in VS Code without their knowledge. Follow him on Twitter @fbricon

Leave a Reply

Be the First to Comment!

Notify of