Why I Still Prefer Eclipse Over IntelliJ IDEA

Over the years, I’ve observed an inevitable shift from Eclipse to IntelliJ IDEA. Last year, they were almost equal in usage, and I have the feeling things are swaying even more towards IDEA.

IDEA is like the iPhone of IDEs – its users tell you that “You will feel how much better it is once you get used to it,” or “Are you STILL using Eclipse?” or “IDEA is so much better, I thought everyone has switched,” etc.

I’ve been using mostly Eclipse for the past 12 years, but in some cases, I did use IDEA – when I was writing Scala, when I was writing Android, and most recently – when Eclipse failed to be ready for the Java 9 release, so after half a day of trying to get it working, I just switched to IDEA until Eclipse finally gets a working Java 9 version (with Maven and the rest of the stuff).

But I will get back to Eclipse again, soon. And I still prefer it. Not just because of all the key combinations I’ve internalized (you can reuse those in IDEA), but because there are still things I find worse in IDEA. Of course, IDEA has many cool features like code improvement suggestions and actually working plugins for everything. But at least some of the problems I see have to do with the more basic development workflow and experience. And you can’t compensate for those with sugarcoating. So here they are:

• Projects are not automatically built (by default), so you can end up with compilation errors that you don’t see until you open a non-compiling file or run a build. And turning the autobuild on makes my machine crawl. I know I need an upgrade, but that’s not the point – not having “build on change” was a huge surprise to me the first time I tried IDEA.
  
  I recently complained about that on Twitter, and it turns out “It’s a feature.” The rationale seems to be that if you use refactoring, that shouldn’t happen. Well, there are dozens of cases when it does happen. Refactoring by adding a method parameter, by changing the type of a parameter, by removing a parameter (where the IDE can’t infer which parameter is removed based on the types), or by changing return types. Also, a change in Maven/Gradle dependencies may introduce compilation issues that you don’t get to see. This is not a reasonable default at all, and I think the performance issues are the only reason it’s still the default. I think this makes the experience much worse.
• You can have only one project per screen. Maybe there are those small companies with greenfield projects where you only need one. But I’ve never been in a situation where you don’t at least occasionally need a separate project — be it an “experiments” one, a “tools” one, or whatever. And no, multi-module Maven projects (which IDEA handles well) are not sufficient. So each time you need to step out of your main project, you launch another screen. Apart from the bad usability, it’s double the memory, double the fun.
• Speaking of memory, it seems to be taking more memory than Eclipse. I don’t have representative benchmarks of that, and I know that my 8 GB RAM home machine is way too small for development nowadays, but still.
• It feels less responsive and clunky. There is some minor delay that I can’t define well, but “I feel it.” I read somewhere that they were excessively repainting the screen elements, so that might be the explanation. Eclipse feels smoother (I know that’s not a proper argument, but I can’t be more precise)
• Due to some extra cleverness, I have “unused methods” and “never assigned fields” all around the project. It uses Spring, so these methods and fields are controller methods and autowired fields. Maybe some Spring plugin would take care of that, but Spring is not the only framework that uses reflection. Even getters and setters on POJOs get the unused warnings. What’s the problem with those warnings? Those warnings are devalued. They don’t mean anything now. There isn’t a “yellow” indicator on the class either, so you don’t actually see the number of warnings you have. Eclipse displays warnings better, and the false positives are much less common.
• The call hierarchy is slightly worse. But since that’s the most important IDE feature for me (alongside refactoring), it matters. It doesn’t give you the call hierarchy of default constructors that are not explicitly defined. Also, from what I’ve seen, IDEA users don’t often use the call hierarchy feature. “Find usage” I think predates the call hierarchy, and is also much more visible through the UI, so some of the IDEA users don’t even know what a call hierarchy is and repeatedly do “find usage.” That’s only partly the IDE’s fault.
• No search in the output console. Come one, why I do I have an IDE where I have to copy the output and paste it into a text editor in order to search? Now, to clarify, the console does have search. But when I run my (Spring Boot) application, it outputs stuff in a panel at the bottom that is not the console and doesn’t have search.
• CTRL+arrows by default jump over whole words, and not camel-cased words. This is configurable but is yet another odd default. You almost always want to be able to traverse your variables word by word (in camel case), rather than skipping over the whole variable (method/class) name.
• A few years ago when I used it for Scala, the project never actually compiled. But I guess that’s more Scala’s fault than of the IDE.

Apart from the first two, the rest are not major issues, I agree. But they add up. Ultimately, it’s a matter of personal choice whether you can turn a blind eye to these issues. But I’m getting back to Eclipse again. At some point, I will propose improvements in the IntelliJ IDEA backlog and will check it again in a few years, I guess.