IntelliJ Platform Roadmap for 2020

Dmitry Jemerov

We’d like to unveil some of our current efforts to improve IntelliJ IDEA and the other IDEs based on the IntelliJ Platform. The results of these efforts are going to be released over the next year, some as soon as in the 2020.1 release in the spring. They are centered around two main themes: performance and support for modern development workflows.

Performance

Indexing Performance

Two of the main pain points related to the performance of our IDEs are startup performance (a tool that takes a long time to start is perceived as heavyweight) and indexing speed. We did a lot to speed up startup during this year, and next year we’re turning our attention to indexing performance.

We’re taking a multi-pronged approach to this problem. First, we’re making it possible to use prebuilt index chunks, so that every IntelliJ instance on the planet doesn’t have to do the same work of indexing the java.lang.String class. We plan to roll out the support gradually over the course of the year, starting with the JDK and then covering libraries from Maven Central, as well as interpreters and packages in other IDEs. We’re also investigating ways to support sharing of index chunks for project source code within a team or an enterprise, but we don’t have any specific plans at this point.

Second, we plan to make indexing less disruptive by making many more IDE actions available during indexing.

Third, we’re going to detect and notify you about indexing anomalies, including files that take too long to index, files that are reindexed too frequently, and index rebuilds caused by exceptions. Our aim is to provide clear steps for resolving such issues and improving the performance of our IDEs on your projects.

And of course, we plan to invest in good old performance optimizations to make sure that the indexing system doesn’t do any unneeded work and has no avoidable overhead.

Read/Write Locks Threading Model Redesign

Another major pain point for our users is UI freezes. This year we built the infrastructure for reporting such freezes and made architectural changes to fix a lot of them (for example, asynchronous listeners for file system events). Over the next year and beyond that, we plan to make an even bigger step and move actions requiring a write lock out of the UI thread.

Back in the very early days of IntelliJ IDEA, an architectural decision was made that required most operations that modify the IDE’s internal data structures to run on the UI thread. This means both basic actions (inserting a character into a document) and large-scale operations (renaming a method with a thousand usages). The benefit of this architecture is a simple programming model, but the obvious downside is that the UI responsiveness suffers in many scenarios.

Over the years, we’ve been finding ways to work around the limitations of this architecture, mostly by splitting large operations into parts that run in the background and that are applied in the UI thread. A more fundamental solution would be to get rid of the UI thread requirement entirely, but up until recently we didn’t know how to do this without major rewrites of our own code and third-party plugins. Now we have an architectural solution that allows for step-by-step migration, and we’re starting the work on implementing it.

Next year we are going to refactor the essential UI components and APIs of the IntelliJ Platform to employ the new threading model. Once the new model is stable and the improvement is perceivable, we’ll switch to the new model in all IDEs, making the UI smooth and lag-free.

Loading and Unloading Plugins Without Restart

For this feature, you’ve already seen a sneak preview in IntelliJ IDEA 2019.3, which lets you install theme and keymap plugins without restart. In 2020.1, we plan to extend this support to all types of plugins. We’ll support load and unload without restart for a large percentage of bundled plugins, and we’re providing support instructions for third-party plugin developers. At this phase, the most important user benefit will be seamless plugin upgrades, not requiring IDE restart.

The end goal of this effort (for versions beyond 2020.1) is to have an IDE that right-sizes itself for every project that you open in it. The Spring plugin will be loaded only for projects that use Spring, the Angular plugin will be loaded only for Angular projects, and so on. If you don’t use a technology, you won’t see any UI elements related to it, and you won’t see any impact on performance or memory usage from the plugin supporting that technology.

Workflow Support

Collaborative Editing

Collaborative editing is the highest-voted request in our issue tracker, and we’re happy to announce that we’re working on it. In the approach we’re currently pursuing, there will be one primary IDE, running on the machine where the source code is located, and other users will be able to connect their IDEs to the primary one as “thin clients”, not requiring direct source code access. Every connected user will have its own state (set of open files, caret position, completion variants list, etc.), with the option to “follow” another user if desired.

“Thin client” users will have access to core IDE features such as navigation, completion and debugging, but not the complete feature set. (For example, in the initial version thin clients may not able to perform version control operations.) Note that the full feature set for thin clients is undecided at this time, and we won’t be able to answer questions about when or whether a specific feature will be supported.

Collaborative editing support is based on the Rider protocol, so most likely it will initially be released in Rider and then extended to other IDEs. In any case, please don’t expect any work in this direction to be released in IntelliJ IDEA 2020.1 – this is a longer-term effort.

Also note that our current approach to collaborative editing is based on our own protocol and will not support interoperability with non-JetBrains IDEs.

We’re considering the possibility to extend the “thin client” approach to other scenarios beyond collaborative editing, such as running the IDE backend in the cloud, but we aren’t ready to announce specific plans in that area.

Cloud Execution Support

For quite some time, many JetBrains products have supported running and debugging your code on machines other than yours, or inside containers. However, not much was shared between the implementations of these features in different products, and even basic features such as Docker support have inconsistent UI.

Now we’re introducing a general concept of a target environment, which provides a way to copy files from or to it, and to start processes there. In IntelliJ IDEA 2020.1, the supported environments will include your local machine, a Docker container or a machine connected over ssh. The choice of the target environment will initially be available for Java and Go run configurations.

Over the subsequent releases, we plan to unify our existing Docker and remote interpreters support around the new architecture. In addition to that, we’ll provide deeper cloud integration, so that you’ll be able to say that the process needs to run on a new VM in the cloud without specifying the details of a specific machine to connect to.

Project Model Redesign

The project model is how the IDE represents the structure of your project – which files belong to the project, how they depend on each other, which libraries are used, and so on. IntelliJ IDEA’s project model has served us well over the years, however, it has certain limitations. First, it doesn’t support arbitrary mixing of projects of different types. For example, AppCode can open an Xcode project and Rider can open a Visual Studio solution, but there is no way to open a Gradle project and an Xcode project in the same IDE frame. Second, the project model works on the level of directories, not files, and it can’t represent different files in the same directory having different dependencies. This makes it difficult to integrate build systems such as Bazel into the IDE, and presents challenges in other scenarios.

The redesigned project model, which we internally call “workspace model”, will remove these limitations. It also brings additional benefits such as better performance during project opening, smoother synchronization with Maven and Gradle, and a nicer programming model. We’ll start with changing the internal implementation to the workspace model, and once this is stable, we’ll proceed to adding user-visible features such as combining projects of arbitrary types in the same IDE frame.

Summary

The efforts described in this post are only a small part of what our team has been working on, and we plan to publish more information on our plans after the holidays. Of course, all of this is subject to change, and it’s quite possible that some of the work described above will not be released, but we’ll have other awesome stuff for you instead.

Feel free to leave your feedback in the comments below. And please stay tuned for Early Access Program announcements, in which we’ll let you know when some of this work is ready for you to try.

Happy Developing!

Subscribe to IntelliJ IDEA Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!