“When working on code inspections, you meet Java puzzlers every day”: Tagir Valeev about working on IntelliJ IDEA

Some people know Tagir lany Valeeva from his reports on the Stream API, others know about habraps, and others know how to work on static code analysis (in the FindBugs and HuntBugs projects). And since August, he has been working at InteBillia IDEA at JetBrains, and this has influenced a lot: he is now doing the code analysis there, and his next report (on the upcoming JPoint and JBreak ) will be about creating code inspections in IDEA. We asked Tagir about how to develop a project that develops everything else.

- How did you start working on IDEA? He himself was an active user and wanted to develop a tool, or were the reasons completely different, and had he been sitting at Eclipse / NetBeans before?

- Before working at JetBrains, I almost did not use IDEA. Basically sat in Eclipse. Sometimes I had to work in NetBeans because we wrote an RCP application on it.
')
I wanted to work on analyzing Java code, and for this IntelliJ IDEA is the perfect place. I used to move FindBugs, then I started writing my static bytecode analyzer for Java HuntBugs , but it’s still clear that IDEA has already done a huge amount of work, and most importantly, it’s not necessary to drag everything. It is more pleasant to do something unique, and not to catch up with others. And, of course, the code analyzer, initially integrated with the IDE, is much more useful, because you can often make a quick-fix, which fixes a problem in the code in one click. View FindBugs output (even if it is integrated with the IDE) and fix everything manually by hand is much lazier. As a result, people stop caring about static analysis altogether, even if they are running on a build server.

- There are cases when the analysis is more convenient just without an IDE - for example, the developer wants to quickly check someone else's code that came to him. In a situation where FindBugs is sticking to the legacy, and now you don’t have time for HuntBugs, is there a feeling that, with all the convenience of analysis, the IDE also leaves an empty niche?

- Yes, I agree, there is a certain failure. Code analysis in IDEA can be run from the command line, without raising the UI, in addition, it integrates with TeamCity and UpSource. But, as far as I know, there is no integration with Jenkins or stupidly maven-plug-in. It could be done at least for IDEA Community Edition, where the issue of license verification does not arise, but, in my opinion, this is not a priority for the company now. Moreover, integration with IDEA is selling point TeamCity and UpSource. On the other hand, it looks like an easy task. In principle, any enthusiast could make friends IDEA Community Edition and Jenkins, many would benefit from it. It would be convenient if a Jenkins label was drawn on any pull request or commit where new and fixed problems would be shown in the code.

“Working on IDEA is such a meta-level,“ developing the main development tool ”. And therefore, it is curious to ask a person “from the inside”: how does this development differ from the usual in practice?

- Yes, there are interesting features. Of course, in other cases, it happens that the developer himself uses the project that he is developing. But when developing IDEA this is maximized. I usually update the main IDEA installation every day or every other day (this simplifies JetBrains Toolbox) from the nightly build and work with the most recent code I wrote myself yesterday. Some developers update the installation with a special script directly from the current code downloaded locally. This helps to catch many bugs before they are seen by external users, or to understand that the new feature is not very convenient. Well, in general, it's nice to use what I did myself. For example, I wrote several improvements for the DevKit plugin, which helps develop IDEA itself or plugins for it. The next day, it becomes more convenient to work.

- And when working on inspections, do you feel that they will benefit you tomorrow when working on the next ones? And do you use them actively for refactoring of already existing code?

- We try not to touch the existing code en masse unnecessarily, in order not to complicate the history of git and not to break what already works. I personally would like to apply some things globally. Say, the cycle with the removal of elements from the collection is conditionally rather well replaced by my inspection on Collections.removeIf, which is not only shorter and clearer, but also, for example, for a large ArrayList works significantly faster than deletion by an iterator. When deleting each element, the iterator will shift the internal array, and removeIf will shift everything once. If I start touching the code that no one has touched for a long time, I, of course, try to simplify it, and the inspections help me with this.

Not all of my inspections come to me personally when developing a new code, because if the inspection replaces a non-optimal code with a more optimal one, it is easier for me to write a more optimal one right away. Others might simply not know that there is a better option, but I know, once the inspection was done. However, conversion of streams into cycles and cycles into streams sometimes help. It is not always obvious which code variant is simpler and more beautiful. Say I wrote a stream in the middle of a method and found that it captures two mutable variables. Changing the code so that they become immutable is inconvenient. Copying them before streaming into new variables is ugly, better cycle. Well, I took advantage of the inspection, deployed stream in the cycle.

- With the conversion of streams into cycles, it came out unexpectedly: you are known as a stream enthusiast, did conversion from cycles to them in IDEA, and then suddenly turned into the opposite. Do users often need this counterintuitive feature? Do users begin to contradict each other's wishes?

- In the case of inspections, counterintuitive requests from users do not interfere with us: you can do two inspections, one replaces A with B, and the other replaces B with A, and let the users decide what they like. Many people really do not like or do not understand the stream and it is more pleasant for them to unfold the stream, written by a hipster colleague, into a cycle. But there are objective flaws in the streams: there are simply no some operations, it is more difficult to debug, it is difficult to throw a checked exception or modify a local variable. Say you wrote a stream and then realized that you needed an early exit by condition. The takeWhile operation will only appear in Java 9, third-party libraries like the boss does not allow StreamEx to use. And here, in two clicks, you can stream into a cycle and add the necessary break. In general, I am deeply convinced that this is a useful feature.



- In a recent issue of No Slides, Maksim Shafirov admitted that dogfudding, with its benefits for JetBrains, is still limited: you feel some problems very well in your own skin, but you don’t come across others personally. Do you often come across situations where people use IDEA in a completely different way than you, but in the end they need something that you wouldn’t guess? How much does the experience of previous work help you, where did you yourself see the IDE from the same angle as now?

- I often see that people write only strange code. Write three method calls where you can write one. They write ten lines, removing an extra copy from the collection, where you can write three lines and not copy. This can be seen on requests to YouTrack (for example, recently closed one ), on the code I see on GitHub, and even on the IDEA code that other developers write. Apparently, many programmers have learned several API methods or classes and are trying to reduce all the tasks to them. In this regard, it is very useful to read someone else's code, because it would never occur to me to write so strangely. You see the obvious nonsense in someone else's code, which IDEA does not highlight - the thought arises to write a new inspection.

In a sense, the Eclipse experience helps me. In general, his Java-tooling is noticeably worse than that of IDEA, but this does not mean that it is worse on all fronts. I really miss some of the pieces after Eclipse, and maybe something I will do without which I suffer.

- You are actively communicating with other developers (you sit in the chat of “Debriefing”, tweet, write habraposts), and often IDEA becomes the topic of discussion. Does such communication help in working on it, or is it for the soul?

“It also happens that I turn complaints in a chatika into a bugreport and correct it.” Of course, I am not an official support channel, so there is no need to abuse it. In general, for the soul, yes. To enhance the feeling that what we are doing, someone needs.

- When you started looking at the IDE from the inside, was there anything surprising? For example, when you first think over the years “why did this be so idiotically done” - and then suddenly you discover that there is a good and non-obvious reason.

- Something I do not remember such examples. I think if something looks idiotic to the user, this cannot be justified by the peculiarities of the architecture. It’s better not to be very beautiful inside, outside the IDE sees much more people than from the inside.

- When the new version of IDEA comes out, people vigorously discuss the things that are conspicuous: hints with the names of the parameters, the recent change of icons, and so on. And how does it look to you from the inside: “everyone is discussing the tip of the iceberg, not noticing the main thing”, or is this really the main thing that happens?

- It is difficult to say which change is more important. Which has most accelerated user experience? For which we spent the most time? Which caused the most enthusiastic reviews? Of course, many things are being done that no one sees. For example, work continues continuously on unloading the UI stream ( Event Dispatch Thread ) and the separation of logic and display. Back in 2016.3, it was possible to take a lock on writing a file in a UI stream, and then, without removing it, display the UI dialog. Taking a lock may imply waiting until the file releases another thread. Now we struggled with this: it is forbidden to take write-lock in the UI stream. Of course, I had to shovel a lot of code that tried to output the UI during locking: somewhere they deleted unnecessary write-locks, and somewhere they carried out the UI-code from them. This took a lot of man-hours, but the user will notice only a slight increase in responsiveness of the IDE. What is there to discuss vigorously?

- By the way, it’s curious to ask about changing the icons: do you have any feelings from her?

- I honestly did not notice anything, because I was not an IDEA user. Either new icons appeared in internal builds before I joined the company, or it happened during the first weeks, during which I did not have time to get used to the old ones.

Honestly, I don’t know why people pay so much attention to icons. While working in IDE, I look at the code, not the icons. To open a class or file, I do not shuffle in the project tree, but use hotkeys like Ctrl + E, Ctrl + N, Ctrl + Shift + N. I sometimes look in the tree with icons when I create a new directory or a new file (although it is often easier to copy an existing file through F5, enter a new name and delete the contents). The toolbar is hidden in my menu, I usually don’t climb in the menu either, preferring Ctrl + Shift + A and entering an action with text (or a specific hot key). I have been using IDEA recently and probably not optimally yet. I think, over time, I will see the icons even less. Let them be at least in the style of Windows 3.1, I do not really care.



- To the question that JetBrains are actively using their own products: but what are the products that are not from JetBrains used when working on IDEA?

- Well, git, for example. It is used by Confluence, for example, for publishing EAPs and for some internal purposes. Java is not from JetBrains. Profilers some. Well, a web browser ...

- For 16 years, projects inevitably overgrow with legacy problems that impede progress. What measures are you taking to combat this?

- In the IDEA code is not so bad. Much more good than bad. There are obvious problems (for example, with API for plugins). Something illogical scattered on the project. But all this does not grow moss, but is regularly refreshed. The usual measures: to refactor here, to refactor there.

- In continuation of the previous question: how do you live with the Swing interface in 2017, when Atom and Visual Studio Code are doing everything on Electron? Does it get in the way or not?

- I almost do not deal with UI and hardly know about the serious difficulties in it. I know that many Swing problems (for example, lack of HiDPI support) JetBrains actively fixes in its JDK fork. I have some prejudice about the UI on HTML / JS, although everything is on it now. There is too much freedom, perhaps, too little order. I remember, on the sidelines of Joker 2015, the guys from JetBrains were discussing thoughts of rewriting UI in JavaScript, and Nikita Lipsky discouraged them. If I understand correctly, now such a conversation is not actively conducted - it means that, in principle, you can live with Swing for now.

- Now it is increasingly heard about Language Server Protocol - and you do not see any reason to participate in this, or can it still change?

- I don’t think that this is a priority for today, but everything can change. Record in the tracker on this topic, of course, is .

- It is known what a big role Stack Overflow plays as a regular developer. And with tasks like yours, does it turn out to be useful or not?

- I rarely find answers to Stack Overflow in my work. Usually to questions in which I am completely new. Let's say I need to fix the gradle script. I never wrote them, but thousands of people wrote, so here Stack Overflow will probably help me in something. And if I already understand something quite well, I usually have questions that are easier to figure out the answer in other ways. For example, looking at the source code or documentation: if the subject is not new to me, I probably already have some idea where to look.

- At JPoint and JBreak, you will give a talk on Java inspections at IntelliJ IDEA - can you already give some example of what you are going to tell there?

“For example, you write an inspection that suggests using Map.getOrDefault where possible. Let's say you have this code:

public Number get(Map<String, Number> map) { return map.containsKey("foo") ? map.get("foo") : 0.0; } 

Inspection will offer to replace it with this:

 public Number get(Map<String, Number> map) { return map.getOrDefault("foo", 0.0); } 

Everything is normal here, the resulting code is correct and semantically equivalent to the original one. So, you found a ternary operator in the source, found out that the condition is map.containsKey, map is of type java.util.Map, in the true branch map.get, the qualifier of map.containsKey and map.get is the same variable, the map.containsKey argument and map.get are the same "pure expression", and in the false branch is a constant. Then we emphasize the code and suggest replacing it with map.getOrDefault, where the first argument is map.get argument and the second is a constant from the false branch. What have we not considered? Where can Java give us a pig? What code does such an inspection break down? These are the questions we will discuss in my report.

- At JPoint 2016, you, with Baruch Sadogursky and Yevgeny Borisov, represented jazz puzzleers (and at JPoint 2017, it may be a continuation). Many perceive puzzle-makers as “these are curious curiosities, but they seldom affect my work” - and it turns out that they affect your work often and strongly?

- When working on code inspections, these puzzle players are every day. Any inspection can run into a nontrivial case where the use of quick fix makes the code non-compiled or, worse, quietly without warning changes its semantics. You need to know the language well to think about it before users start complaining. An IDE developer, of course, must know all the hidden corners of the language specification.



If you have not seen last year's performances Tagir at the Moscow JPoint and Novosibirsk JBreak, we recommend - the audience praised them highly:

• Stream API: recommendations of the best dog breeders (JBreak 2016)
• Oddities Stream API (JPoint 2016)
• Java 8 Puzzlers (JPoint 2016, with Baruch Sadogursky and Yevgeny Borisov)

The following JPoint and JBreak , where Tagir will give a report on inspections, will be held in April - and from February 1, tickets for them will go up. So, if after the interview I wanted to see the whole of his speech and other reports from these conferences, now is the time to act.