IntelliJ Platform Roadmap for 2020
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.
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!
47 Responses to IntelliJ Platform Roadmap for 2020
Jonas says:December 19, 2019
Nice! Let’s get better together
ADEV says:December 19, 2019
Great, 2020 will be an amazing year
Please make sure you develop features with Valhalla in mind, adopting a data oriented design will provide huge speed boosts once value types will be there
Mark Vedder says:December 19, 2019
Some nice changes coming. With Dynamic Plugins, a great related feature would be the ability to specify on a project by project basis specific plugins to enable when opening a project. For example, if I have a legacy project that use Ant, or Struts but otherwise do not use those plugins, I would like those plugins to (automatically) load only when I open that legacy project. Of course this just doesn’t benefit legacy projects. There are current projects that use a one-off technology or framework. And having to always load that plugin (taking up resources and UI real estate) for the intermittent occasions when it is needed has always been a pain point. And while being able to Dynamically enable & disable them in the future is a great step, it would be nice when we go to work on some one-off project to not have to remember to enable needed plugins, and more crucially to later disable them.
Dmitry Jemerov says:December 20, 2019
Yes, we do plan to support explicitly specified per-project plugins.
Alexey Dmitriev says:January 6, 2020
is there an issue I can follow/like
Dmitry Jemerov says:January 7, 2020
Gaetan Zoritchak says:December 20, 2019
What a great post!
Thanks a lot for sharing the current work in progress. The lack of feedback on the collaborative issue was a little bit frustrating, but you give with this post so much information. It gives us some visibility on the complexity of the challenges to tackle. Kudos for the team.
Sergio says:December 20, 2019
If Cloud Execution environments included WSL in Windows that would be golden!
It’s the only thing that I envy from VS Code, how I can type “code file.txt” from my Linux subsystem and the IDE runs seamlessly in Windows.
Diego Medeiros says:December 20, 2019
Great. I think that sync scratch files by account could be greatest
Dmitry Jemerov says:December 23, 2019
This is not on our current roadmap, but you’re welcome to file a feature request in YouTrack.
Louis CAD says:February 17, 2020
Requested the feature here:
You can vote for it.
Rakesh says:December 20, 2019
It would be really helpful if you can support remote editing feature where I can directly edit code on remote machine rather than checking out code to local machine.
Nicolas Martel says:December 20, 2019
For dynamic plugins, it would be really great if this also extended to plugin development! Being able to test without restarting the editor every time would be groundbreaking stuff for plugin developers.
JJ says:December 20, 2019
Sounds dope. I’ll be waiting for it
Philip says:December 20, 2019
Wow, the list sounds incredible.
Earlier this year, with my corporate license expiring, I ventured out to VS Code. That just gave me a renewed appreciation for IntelliJ, and I enthusiastically renewed my license.
Please keep up the great work.
Reece Dunn says:December 20, 2019
This roadmap looks great. I have a few questions relating to a plugin I support.
It would be useful to have an “Include this config-file if the corresponding plugin is missing” feature in the plugin XML as I am using runtime checks currently for some functionality to prevent them conflicting. — This would help for plugins like mine which can co-exist with some other plugins and provides similar functionality. My specific use case is that I have an XQuery plugin that I am extending to support XPath and XSLT that can co-exist with the XPathView + XSLT plugin, but when that plugin is missing provides XPath syntax highlighting and validation.
How is support for XML-based languages (XSLT, XMLSchema, DocBook, etc.) going to be handled in the “self-righting” behaviour? — Currently, plugins can advertise supported file types, but not XML namespaces.
# Project Model Redesign
Is the API for this going to be compatible with the current API, specifically using the Projects and Modules APIs? That is, if a plugin has project settings and passes around Project objects, is that going to work in the redesign, or will it need rewriting?
Is the new architecture going to be available for all IDEA-based platforms? That is, will the “Project Structure…” dialog be available on platforms like WebStorm?
Dmitry Jemerov says:December 23, 2019
“Include if this plugin is missing” is not currently part of our plans, but you’re welcome to file a feature request.
We don’t have a detailed design for automated loading of plugins depending on project content, but we do want to support more than just file types.
The Project class isn’t affected by the changes; its semantics are shifting towards “everything open in one IntelliJ IDEA window” but the API stays the same. The Module class will become legacy API; it will be supported (most likely for a very long time) but not recommended for new code.
The new architecture will be available in all IDEs, but the Project Structure dialog isn’t part of it. The current Project Structure dialog makes sense only for JPS-based Java projects, so we don’t have any plans to make it available in other IDEs.
zgqq says:December 21, 2019
This is a very great decision.
LinWanCheng says:December 21, 2019
It is hoped that the .idea folder of the git project can automatically add the .gitignore file to ignore the irrelevant files that often change, and retain the files that can directly open the project.
Hope to support git operations for external modules.
original:
希望git项目的.idea文件夹能自动添加.gitignore文件忽略经常变化的无关文件，而保留可以直接打开项目的文件。
希望支持外部模块的git操作。
Dmitry Jemerov says:December 23, 2019
Recent versions of IntelliJ IDEA already create a .gitignore file inside .idea so that the files which are not intended for sharing in the version control.
Git operations for external modules are already supported. You may need to set up a mapping for the module in Settings | Version Control.
Ion says:December 28, 2019
what about javafx vs swing, is rewrite of IntelliJ in javafx viable ?
did you ever considered this 🙂
Dmitry Jemerov says:January 2, 2020
Such a rewrite will involve a huge amount of work with very little noticeable benefit for end users, so we have no plans to do that.
Paul Bauer says:December 30, 2019
What network requirements do you have planned for thin clients?
Will the Rider protocol only work on the same LAN or will there be a proxy with end-to-end encryption a la visual studio live share?
Dmitry Jemerov says:January 2, 2020
We aren’t ready to announce any specific requirements here.
Paul Bauer says:January 7, 2020
Any solution that requires direct LAN access for collaboration is unlikely to work for many users. Any solution that requires opening up specific ports in a corporate firewall is similarly a high barrier. Here’s hoping your solution is as easy to use and universally accessible as VSCode Live Share
Dmitry Jemerov says:January 8, 2020
Yes, of course we’re aware of all of this.
Luis Lobo Borobia says:January 2, 2020
Love the work being done on the Performace Indexing improvements
One typical workflow we have sometimes is nuking the `node_modules` folder because of dependency upgrades, or new modules being added. Of course the IDE detects the change and re-index them all. Most of the time, it’s just some modules being “added” to it.
I’d love to see this use-case being handled nicely.
Raphael says:January 3, 2020
Will the “workspace model” mean that we can use, say, IDEA, PyCharm and DataGrip all in the same project directory?
The language around “IDE frame” is confusing to me.
Dmitry Jemerov says:January 3, 2020
Using multiple IDEs in the same project directory doesn’t depend on the workspace model in any way; this will be supported at some point but it doesn’t require major architectural changes. “IDE frame” basically means a window where a project is open.
Draget says:January 7, 2020
I very much appreciate the performance tweaking.
You mentioned two things which I can really relate to: IDEA was called ‘fat’ by some of my colleagues in the past and now that you mention it, the startup-time could be one of the reasons.
Personally I sometimes caught myself being annoyed by right-clicking some element and having to wait 1-2 seconds before the popup-menu would appear or something would happen. This might be the UI lock issue… which would be great if that got improved.
Really looking forward to this!
I just hope the ‘workspace model’ will not end up exactly like in eclipse. One of the things I did not like about eclipse… that it was so annoyingly complicated to add different projects from different directories across my PC. 😛
Thank you for sharing this post, keep it up! 🙂
Nos Doughty says:January 8, 2020
I’m very heartened to read this post. Of late, I have wondered if the IntelliJ team has had some sort of fundamental shift away from the approach of the early years. It’s hard to put a finger on, but it just seems as though priorities have shifted. I’ve even wondered if the use of Kotlin is starting to backfire.
However, this roadmap is very impressive. It’s not just the plans themselves, it’s the sophisticated way in which these are being pursued. Clearly a great deal of thought has gone into understanding the pain points of the users, and looking for clever solutions that avoid attempts to brute-force simplistic solutions to the problems. Due to this, I would suspect that even partial success on these goals would result in a massively improved product.
Additionally, I would like to specifically applaud the work on the project model redsign. This is for me, and my team, by far the greatest issue. It’s not like any other products do it better (they don’t), but increasingly we have relied on outside project configuration tools and treated our intellij projects themselves as disposable. For myself, personally, I would appreciate smoother integration with maven (I’m sure that gradle users feel the same about their build tool), and where I work we suffer greatly with our mixed language projects (we often use projects with Ruby, Javascript, Java, and C++ mixed together).
So thanks, and good luck with the year ahead.
Sabold says:January 16, 2020
So happy to see that performance is the theme for the whole year. 1 year ago I had to switch to VS Code because Idea was so awfully slow with huge Angular applications. With 2019.3 I never touched VS Code again because while Idea is still slower it just has a ton more features that VS Code will never get. Really looking forward for all the improvements this year, indexing is probably the biggest pain right now, especially a shared index for enterprises sounds absolutely amazing at least in theory.
Jarred Miles says:January 17, 2020
Any word or progress on resharper running out of process for visual studio?
Dmitry Jemerov says:January 17, 2020
Please contact the ReSharper team to get information about their plans.
Frank says:January 17, 2020
Are there any plans to bring the Project Structure Dialog from Android Studio () over to Intellij IDE? The dependencies update check look pretty sweet..
Dmitry Jemerov says:January 17, 2020
Right now there are no plans to integrate Android Studio’s Project Structure dialog. For managing outdated dependencies, we’re working on the Package Search plugin:
Ivan says:January 19, 2020
Make Intellij Idea for Windows on ARM. I want to use it on my Surface Pro X and make native apps for it. Thanks.
Dmitry Jemerov says:January 20, 2020
We’re currently investigating the possibility of supporting IntelliJ IDEA on various ARM-based platforms; we don’t have any definite plan concerning Windows for ARM.
Bric3 says:January 20, 2020
By the way I heard about using metal on the JBR instead of opengl. I’d their true will it improve intellij idea reactiveness on 4k screens?
Dmitry Jemerov says:January 21, 2020
Yes, we’re working on Metal support together with Oracle as part of Project Lanai:
Right now it’s too early to say anything about performance, other than that it’s not a magic bullet that will solve all problems related to rendering performance.
Ilya Murashov says:February 7, 2020
Does Cloud Execution Support mean that it will be possible to develop from a low-spec machine while connected to a more powerful host over the network (e.g. a VM in the cloud)?
Dmitry Jemerov says:February 10, 2020
The feature we’re announcing in this roadmap means that it will be possible to run your IDE locally and seamlessly execute the application you’re developing on a more powerful host across the network.
Piotr Żurek says:May 2, 2020
Will it be possible to host source code in the cloud and use local IntelliJ as UI only? So the IntelliJ in the cloud will be kind of headless IntelliJ, and local is only interface with communication to remote one. That way we will be able to run IntelliJ on low-end laptops and all operations (like indexing, intellisence or find everywhere) will be done on cloud side in very efficient way. Also it will let companies to keep source code secure in the cloud without possibility to copy it on local machine.
Dmitry Jemerov says:May 4, 2020
As the blog post says, we aren’t ready to announce specific plans in that area.
Fred says:March 9, 2020
I’m not sure the UI freeze fixes are working 🙁 I’ve noticed the UI freezing far more in 2020.1 EAP than any previous version – it seems to just lock solid after most edits to method parameter types etc and take several seconds to catch up.
Dmitry Jemerov says:March 10, 2020
The architectural changes described in this blog post are not included in 2020.1 (the post describes the roadmap for the entire year, not for the first release). If you can reproduce the performance problems, please capture a CPU snapshot and report it to YouTrack as described in
Elhanan Maayan says:March 20, 2020
with coronoa running around, you might wanna step up your collaborative editing future 😉