days
-1
0
hours
-1
-7
minutes
-4
-6
seconds
0
-6
search
Making your life as a developer easier

New in Eclipse JDT language server

Fred Bricon
MicroProfile
© Shutterstock / Sadovski

Have you heard about Eclipse JDT Language Server (a.k.a. jdt.ls)? 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 jdt.ls 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, jdt.ls 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, jdt.ls leverages the latest milestone developments from the Eclipse Photon SDK.

jdt.ls integrated everywhere

While vscode-java is the reference implementation for jdt.ls clients, others have jumped on the jdt.ls 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 jdt.ls 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 jdt.ls.

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 jdt.ls :

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 org.eclipse.jdt.ls.core.delegateCommandHandler in their plugin.xml, with a list of command ids, like :

<plugin>
   <extension point="org.eclipse.jdt.ls.core.delegateCommandHandler">
      <delegateCommandHandler class="com.microsoft.java.debug.plugin.internal.JavaDebugDelegateCommandHandler">
            <command id="vscode.java.startDebugSession"/>
            <command id="vscode.java.resolveClasspath"/>
            <command id="vscode.java.resolveMainClass"/>
            <command id="vscode.java.buildWorkspace"/>
            <command id="vscode.java.fetchUsageData"/>
            <command id="vscode.java.updateDebugSettings"/>
       </delegateCommandHandler>
   </extension>
</plugin> 

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 jdt.ls, should reach feature parity with its old server by providing custom jdt.ls extensions, for instance dependency visualization:

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

Finally, Gorkem Ercan, fearless leader of the jdt.ls project, can satisfy his dogfooding needs by developing jdt.ls with jdt.ls 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 org.eclipse.jdt.ls.core.importers extension point allows 3rd party adopters to expand the types of projects imported by jdt.ls beyond simply Maven, Gradle and Eclipse projects.

What’s next?

The jdt.ls 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 eclipse.jdt.ls channel on Mattermost, or open bug reports (and submit pull requests!) to https://github.com/eclipse/eclipse.jdt.ls

eclipseorb_color

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.

Author

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!

avatar
400
  Subscribe  
Notify of