JetBrains Fleet is a new multi-language programming editor and IDE that represents JetBrains’ attempt to rebuild the entire integrated development environment from scratch. Fleet is separate from JetBrains’ effort to overhaul the user interfaces and user experiences of its existing IDEs, such as IntelliJ IDEA, without changing the IDEs’ code-centric features and integrations. Fleet will not replace any existing JetBrains IDEs.
JetBrains says Fleet was “built from scratch,” based on its 20 years of experience developing IDEs, and featurs “a distributed IDE architecture and a reimagined UI.” For Java, Fleet uses the IntelliJ code-processing engine. For some other languages, Fleet uses a language server, à la Visual Studio Code, instead of the IntelliJ engine.
I said earlier that Fleet is an editor and IDE. When you start it up, Fleet is a lightweight code editor. Once you’ve loaded a code directory, you can turn on “smart” mode, which indexes your code and enables IDE functionality, such as project and context-aware code completion, navigation to definitions and usages, on-the-fly code quality checks, and quick fixes. Indexing a large project can take awhile.
In many ways, the most direct competitor to Fleet is Visual Studio Code, with its language server architecture and large ecosystem of plugins. Fleet already has a language server architecture, but its plugin architecture is still being developed.
Fleet architecture
Fleet uses a distributed architecture that aims at simplicity of use for standalone instances, while also supporting collaborative development, remote/cloud IDEs, and multiple target file systems.
As shown in Figure 1 below, the Fleet architecture includes:
Front end – delivers the UI, parses the files, and provides limited highlighting for supported file types. There can be more than one front end attached to a workspace, allowing for collaborative development.
Workspace – the component whose main purpose is maintaining the front ends’ shared state when there are several of them. It also registers other components to provide information on the available services and APIs.
Back end – a headless service that does the heavy lifting: indexing, static analysis, advanced search, navigation, and the like. Every such operation is initiated by a request from the workspace, which then processes the response and dispatches the data to the components that require it. As a back end, you can use a headless IntelliJ IDEA or a language server. Note that back ends may have different requirements. For example, language servers need to run on the same machine where the source code is located, as shown in the diagram.
FSD (Fleet System Daemon) – a Fleet agent typically attached to the system where source code and SDKs reside. It is used to build the project, run code, execute terminal commands, and perform other actions in the target environment on behalf of Fleet.
Fleet is mainly written in Kotlin, which means it runs on the JVM. The UI framework is a home-grown solution using Skia (via Skiko). Fleet uses Rust for the Fleet System Daemon.
IDG
The diagram shows the architecture of Fleet. Multiple front ends correspond to multiple users, and multiple back ends perform different functions. FSD is the Fleet System Daemon, which is an agent used to build the project, run code, and execute terminal commands. IJ is an IntelliJ engine, and LSP is a Language Server Protocol instance.
Fleet language support
Fleet currently supports development in Java, Kotlin, Go, Python, JavaScript, JSON, TypeScript, and Rust. Support for PHP, C++, C#, and HTML will be available “soon.” Fleet doesn’t yet support Scala, Groovy, or any other programming language not mentioned above.
Installing Fleet
Because Fleet is currently in a closed beta, you need to apply for permission to try it out. Once Fleet is ready, which may be some months, it will be opened up to public preview. Once I had permission to join the closed preview, I installed Fleet from the JetBrains Toolbox app on my MacBook Pro.
Fleet smart mode
Smart mode is required for semantic highlighting, code completion, code refactoring, navigation, find usages, and type information retrieval for parameters and expressions. This list is not exhaustive and may vary for different languages and plugins.
According to the documentation, for Fleet’s smart mode features to work, it may need to execute project code, which might pose a problem when its source is untrusted. Actions like importing projects, running scripts, and executing Git commands may run malicious code. For this reason it is important to enable smart mode only when you trust the code authors.
I consider the whole concept of trusting the code authors to be a bit tenuous for open source projects. There have been several egregious cases where trusted, longtime repository maintainers suddenly went rogue for economic or political reasons, with serious consequences for projects that relied on their code. In general, I trust repositories that require code reviews before check-ins are committed, but the level of trust deserved by repositories with a single contributor is often uncertain.
Fleet code intelligence features are provided by components called back ends. Architecturally, they are separate from other components, so they may run both locally or remotely. Fleet identifies two types of back ends, IntelliJ IDEA-based (a headless instance of IntelliJ IDEA with plugins) and LSP-based (a server that talks to Fleet via the Language Server Protocol).
When you enable smart mode, Fleet launches a particular type of back end depending on the language. For example, Java is handled by IntelliJ IDEA, whereas Rust support is provided by a LSP server.
IDG
Fleet’s Git integration pane is independent of smart mode. Here we see the summary of repository changes in the left-hand tab, despite seeing that smart mode is off at the top right.
IDG
Here we see the progress of a Git pull at the upper right. Smart mode is still off.
IDG
Smart mode enables many code analysis functions in Fleet, such as the usage pop-up shown in the middle of the right-hand pane.
Distributed Fleet configurations
Fleet’s architecture is designed to support a range of configurations and workflows. You can run Fleet only on your machine, or move some of the processes elsewhere—for example by locating the code processing in the cloud.
The two distributed options that currently work are using JetBrains Space as the remote environment, and using a remote machine. Future options include running Fleet in one or more Docker containers, and running Fleet in cloud virtual machines.
The IDE to beat
Overall, JetBrains Fleet is very promising, but not yet ready for wide release. It has several ambitious features that could make it a strong competitor to Visual Studio Code, although Visual Studio Code has the advantages of being free, mature, very popular, and widely supported.
JetBrains has been successful in the past in the face of good, free competition. One need only look at IntelliJ IDEA, which managed to carve a niche for itself in the Java/Scala/Groovy world despite the existence of two free, popular, mature alternatives—Eclipse and NetBeans.
Currently, the most desired missing feature in Fleet (for me) is Markdown preview support. The minute Fleet starts to support old-style JetBrains plugins, it will get Markdown preview along with hundreds of other features. Nevertheless, the roadmap for Fleet includes a new plugin architecture. I’m sure there is a good reason for that, having to do with the updated architecture of Fleet, but I expect that support for old-style JetBrains plugins will happen soon for bootstrap purposes.
There was a time when your choices for Java IDEs were Eclipse, NetBeans, or IntelliJ IDEA. That has changed somewhat. Among other innovations, Visual Studio Code now has good support for editing, running, and debugging Java code through a set of Java-specific extensions.
Visual Studio Code is a free, lightweight but powerful source code editor that runs on your desktop and on the web and is available for Windows, macOS, Linux, and Raspberry Pi OS. It comes with built-in support for JavaScript, TypeScript, and Node.js and has a rich ecosystem of extensions for other programming languages (such as Java, C++, C#, Python, PHP, and Go), runtimes (such as .NET and Unity), environments (such as Docker and Kubernetes), and clouds (such as Amazon Web Services, Microsoft Azure, and Google Cloud Platform).
Aside from the whole idea of being lightweight and starting quickly, Visual Studio Code has IntelliSense code completion for variables, methods, and imported modules; graphical debugging; linting, multi-cursor editing, parameter hints, and other powerful editing features; snazzy code navigation and refactoring; and built-in source code control including Git support. Much of this was adapted from Visual Studio technology.
Extensions to Visual Studio Code can use the Language Server Protocol, which defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references, etc. A Language Server is meant to provide the language-specific smarts and communicate with development tools over a protocol that enables inter-process communication.
In addition, extensions can use the Debug Adapter Protocol (DAP), which defines the abstract protocol used between a development tool (e.g. IDE or editor) and a debugger. The Debug Adapter Protocol makes it possible to implement a generic debugger for a development tool that can communicate with different debuggers via Debug Adapters.
Java extensions to Visual Studio Code
Visual Studio Code has a long list of Java extensions, not all of which are compatible with each other. The easiest way to get started is to install the Coding Pack for Java on Windows or macOS. The next easiest way on Windows and macOS, and the easiest way on Linux, is to install a JDK, VS Code, and Java extensions.
Extension Pack for Java
The Extension Pack for Java bundles six compatible Java extensions, one from Red Hat and the rest from Microsoft. It includes Language Support for Java by Red Hat, Debugger for Java, Test Runner for Java, Maven for Java, Project Manager for Java, and Visual Studio IntelliCode. Each of these is described below. The features of the Extension Pack for Java that were added in 2018 are illustrated with screen video captures in a Microsoft blog post.
IDG
Visual Studio Code Extension Pack for Java. All extensions containing “Java” are shown at the left; the Extension Pack for Java is shown at the right.
Language Support for Java by Red Hat
The Language Support for Java by Red Hat extension provides Java language support via Eclipse JDT Language Server, which in turn utilizes Eclipse JDT, M2Eclipse, and Buildship. The Java Language support goes all the way up to refactoring, which can be found in the context menus.
The Eclipse JDT Language Server is a Java language specific implementation of the language server protocol. It implements the language server protocol and may implement extensions when it is deemed necessary. It also provides project translation from build systems such as Maven—through the use of M2E project—to JDT project structure. Half the contributions to the Eclipse JDT Language Server have come from Red Hat, and about a third have come from Microsoft.
IDG
In the main panel, we’re looking at the source code of one Java file in the context of a large AI program. The pop-up in the upper middle is a peek screen triggered by hovering over the method name.
Debugger for Java
Debugger for Java is a lightweight Java Debugger based on Java Debug Server, which extends the Language Support for Java by Red Hat. Features include launch and attach; breakpoints, conditional breakpoints, and logpoints; pause and continue; step in, out, and over; exceptions, variables, call stacks, and threads; evaluation; and Hot Code Replace (the Java equivalent of Visual Studio’s Edit and Continue).
IDG
Debugging a Java program. Notice the orange highlights to show variable values on the right, and the local variables panel at the top left. The lighting bolt on the right end of the floating debug control part at the top center is the Java Hot Code Replace button, which is similar to Visual Studio’s Edit and Continue feature.
Test Runner for Java
Test Runner for Java is a lightweight extension to run and debug Java test cases in Visual Studio Code. The extension supports the JUnit 4 (v4.8.0+), JUnit 5 (v5.1.0+), and TestNG (v6.8.0+) test frameworks.
Maven for Java
The Maven extension for VS Code provides a project explorer and shortcuts to execute Maven commands. It allows you to generate projects from Maven Archetypes, and generate POMs (Project Object Models); provides shortcuts to common goals, plugin goals, and customized commands; and preserves command history for fast re-runs.
Project Manager for Java
Project Manager for Java is a lightweight extension to provide additional Java project explorer features. It works with Language Support for Java by Red Hat to provide a Java project view, create Java projects, export JARs, and manage dependencies.
Visual Studio IntelliCode
The Visual Studio IntelliCode extension provides AI-assisted development features for Python, TypeScript/JavaScript, and Java developers in Visual Studio Code, with insights based on understanding your code context combined with machine learning. Contextual recommendations are based on practices developed in thousands of high quality, open source projects on GitHub each with high star ratings. This means you get context-aware code completions, tool tips, and signature help rather than alphabetical or most-recently-used lists. By predicting the most likely member in the list based on your coding context, AI-assisted IntelliSense stops you having to hunt through the list yourself.
Other Java extensions of note
Check out Tomcat and Jetty if you’re working with those technologies.
And you might find Checkstyle handy when you need coherent code style, especially across multiple team members.
Running Visual Studio Code
There are currently at least four ways to run Visual Studio Code: the original desktop app, which runs on Windows, macOS, and Linux; online in a browser, with reduced functionality; online with Gitpod; and online with GitHub Codespaces. A fifth possibility is to use Visual Studio Code Remote – Containers; I won’t show you that because it looks essentially the same as using Gitpod and Visual Studio Code, with the difference that it uses a local instance of Docker.
Visual Studio Code Desktop
This is the OG version of VS Code, with full features.
IDG
Visual Studio Code editing and running a ShellSort implementation in Java locally, after checking out the TheAlgorithms/Java project from GitHub. We’re seeing the project structure in two views (files and classes) on the left, the source code on the top right, and the output on the bottom right.
Visual Studio Code for the Web
This is a reduced-functionality, web-hosted VS Code editor. It can only run a few extensions, and can’t debug or run your code. It’s still useful for making small changes to the code directly in the repository without installing anything.
You can activate Visual Studio Code for the Web by browsing to https://vscode.dev, or by changing the “.com” domain in repository address to “.dev” for supported sites, such as GitHub. To switch to a full-featured environment from Visual Studio Code for the Web, you can use the “Remote Repositories: Continue Working On…” item from the command palette.
IDG
Visual Studio Code Online. Notice the “dev” domain. You can edit in this environment, but most VS Code extensions won’t install and you can’t run or debug your code.
Visual Studio Code in Gitpod
Gitpod is a GitHub, GitLab, and Bitbucket add-on that can open a development environment for you directly from a repository. Visual Studio Code is only one of the IDEs that Gitpod supports, and it can install extensions, run code, and debug. Gitpod can open VS Code workspaces online in a browser, or in an instance of VS Code connecting remotely to the repository as shown below.
In addition to VS Code, Gitpod supports IntelliJ IDEA, command-line editors such as Vim, and editors running in Docker containers for Java development.
IDG
We’re looking at Visual Studio Code using SSH to connect to a GitHub repository under the control of GitPod. We’re not editing a local checkout of the repository; instead, we’re using a local instance of VS Code to work with the repository directly.
GitHub Codespaces
GitHub Codespaces (beta) offers a development environment that’s hosted in the cloud. You can customize your project for Codespaces by committing configuration files to your repository (often known as “configuration as code”), which creates a repeatable codespace configuration for all users of your project.
Codespaces run on a variety of VM-based compute options hosted by GitHub.com, which you can configure from two-core machines up to 32-core machines. You can connect to your codespaces from the browser or locally using Visual Studio Code.
IDG
Invoking a cloud GitHub Codespace from GitHub. Drop down the code menu and pick the Codespaces pane, then click the green button at the bottom.
IDG
Debugging a Java program using a Codespace in a browser. I used the default four-core workspace size and started with App.java, which does nothing more than print a line. Here I’ve stepped into the library code. Note the call stack and the local variables at left.
IDG
Here we’re almost finished debugging, and the console shows the printed line.
VS Code for Java?
Overall, Visual Studio Code is very good as a Java IDE if you install the Extension Pack for Java. It’s merely OK as a Java editor without the extension pack, as becomes obvious when you run Visual Studio Code for the Web.
It speaks highly of Visual Studio Code that it has inspired so much energy from its open source community, even to the point where Red Hat has contributed heavily to its Java support. It also speaks highly of Visual Studio Code that it has been adopted for a third-party product like Gitpod, and for GitHub Codespaces. (GitHub is a Microsoft subsidiary.) I’m actually more impressed that VS Code has been adopted across groups at Microsoft than I am at the open source contributions, as the company has historically had more than its share of internal inter-group rivalries.
Would I drop my current Java IDE in favor of Visual Studio Code? Probably not. I’ve had large Java projects that wouldn’t build in VS Code on my 8 GB MacBook Pro—it ran out of memory. The same projects built just fine in Eclipse, NetBeans, and IntelliJ IDEA on the same machine with the same background programs running.
On the other hand, I prefer Visual Studio Code for quick edits and work on small projects. You might prefer it for full-time Java work. It’s certainly worth trying out.
IDG
IDG
IDG
IDG
IDG
IDG
IDG
IDG
IDG
IDG
IDG
IDG
IDG
