Eclipse, IntelliJ IDEA and my journey there and back again

There are two ways to draw attention to an article. Give it a sensational headline or write a sensational tweet linking to it. I originally wanted to do neither and ended up doing both. Add IntelliJ IDEA and Eclipse, a subject developers feel about as fiercely as the situation in the Middle East, and I'm on thin ice and in the very situation I wanted to avoid. After more than six months of daily use, I decided to leave IntelliJ IDEA and go back to Eclipse. Here's why.

How I came to IntelliJ IDEA

I ended up with IntelliJ IDEA partly by chance and partly because of the people around me. Almost all my colleagues switched from Eclipse to IntelliJ IDEA and raved about it. At one point Eclipse stopped downloading source files for Maven artifacts. After one of those security changes that definitely can't break anything, dude, connecting to the company Maven repository over HTTPS started to require SNI support. That meant replacing a library Maven uses for HTTP communication. That's simple for a Maven installation somewhere on disk and much harder for Maven inside Eclipse as an OSGi bundle. I spent some time on it and couldn't get it working. Eclipse can use an external Maven for certain tasks, but dependency resolution always uses the embedded Maven.

All the IntelliJ IDEA users around me said that this worked for them. I told myself it sometimes pays to step outside your comfort zone to make progress and learn something new. Broken source downloads, great reviews from colleagues and the desire to learn something new all added up. There wasn't much to think about. I decided to start using IntelliJ IDEA. Naturally I couldn't help comparing it to Eclipse from the beginning. The notes I took became the basis for this article.

Why I went back

IntelliJ IDEA and Eclipse are both excellent development environments with roughly the same range of features and gadgets of varying use to developers. When you start comparing them, you unwittingly do one or the other a disservice. I understood that once I figured out why IntelliJ IDEA didn't suit me. Every developer has their own way of working in an IDE, and the IDE either fits it or it doesn't. You might say, and I'm making this up, that IntelliJ IDEA has better XML support. That's beside the point for a developer who last saw XML in a J2EE course ten years ago and has since written Java applications for embedded devices. The relationship between the IDE and how you work goes both ways. If you start programming in Eclipse, the habits you pick up there will shape how you work. When you change IDEs, naturally you compare how comfortably you can work the same way. Sometimes you can, sometimes you can't.

My way of working wasn't a good or comfortable fit in IntelliJ IDEA. I'll go through the things that didn't suit me. I may have been able to reconfigure some of the behavior that bothered me, but either I couldn't figure out how or it didn't behave quite the way I'd hoped.

Major obstacles

Here are the things I never got used to, despite trying hard. At best they irritated me, and at worst they drove me out of my chair. I'll exaggerate a little to keep it entertaining. I hope the IntelliJ IDEA authors will forgive a little humor, and I apologize to any offended fanatics of this otherwise splendid IDE.

A few things are central to how I work in an IDE. I spend most of my time in the Java editor, working in quick cycles of compile, test and refactor. I often write pieces of code as prototypes and polish them as it suits me. I run tests often, and I often have parts of the project that won't compile. When I'm working on one class and its test, I don't need the rest of the prototype code to compile. I use code completion a lot to understand a class's API, and for that I need to see its documentation instantly.

Compiler

The first time I used the compiler, I felt like it was 2002 again and I was a beginner working in JBuilder. May it rest in peace. I consider the compiler and its seamless integration with the rest of the IDE essential. I can get past practically anything, but something is wrong if using the compiler feels like going back a decade, and in more than one respect. I'd raise an eyebrow if a $15 text editor behaved this way, but for $500 software I can't wrap my head around it.

• Compile on save. IntelliJ IDEA compiles source code only when it actually needs to. If you edit a class in debug mode, save it and expect the code to update in the running JVM on the next pass, nothing happens. Only once you realize you have to compile the class explicitly does IntelliJ IDEA graciously offer to reload it in the running JVM.
• Compile and proceed on error. If your project has a compilation error and you want to run a test, for example, you're out of luck. IntelliJ IDEA tries to compile the whole project first even if the test has nothing to do with the compilation error. A kind soul on Twitter advised me that you can remove the test phase's dependency on the compile phase. I eagerly did that and then spent an hour scratching my head about why the current version of the class wasn't being used. The answer was that there was no compile on save, so I had to compile every changed class explicitly. If your way of working involves refactoring partly debugged pieces of code, this approach is doomed from the start.
• Performance. Because compilation is deferred until you need it, for example when running tests, it naturally takes longer then because all the changes have to be compiled. If compiling one seven-line class with an error takes two seconds, according to the IDE itself, sooner or later it gets on your nerves.

Contextual help

IntelliJ IDEA set out to teach you the order and meaning of method parameters, and even their documentation, by heart. I type System.out. and press ctrl+space in the vain hope of seeing documentation for each method. When I finally find the method I want and forget what the third of its five parameters means, I expect the same ctrl+space to tell me at least its name. Unfortunately, the first shortcut you have to learn is cmd+P to show the parameters. The second, no less important, is ctrl+J to make the IDE show or refresh the Javadoc window for the current context. That's frustrating for someone used to getting the whole context one way, through code completion. It is especially annoying when you're working with an API you don't know.

Small things

These are minor annoyances, to a greater or lesser degree. They all have workarounds.

Favorite static imports

If you write tests often, you know most of the API consists of static methods on just a few classes (Assert, CoreMatchers, Mockito). In Eclipse you can configure those classes for code completion. The IDE then suggests them automatically and adds a static import. If I type mock anywhere in Eclipse and invoke code completion, the IDE offers the relevant methods from org.mockito.Mockito and adds a static import for the one I choose. In IntelliJ IDEA I had to import the class first and then have it statically import the particular method.

Keyboard shortcuts

For some reason the shortcuts felt Windows-centric and out of step with the operating system's conventions. Closing the editor with cmd+F4 when the rest of MacOS uses cmd+W is odd, to put it mildly. Some shortcuts stretch your fingers more than they help. Try ctrl+J to refresh the documentation window on a MacBook keyboard with no right ctrl key.

No Display window when debugging

I got used to Eclipse's Display window when debugging. It lets me write code and run it in the debugging context while the debugger is stopped at a breakpoint. IntelliJ IDEA had something similar, but the window was always a pop-up. It starts to get annoying when you want to run the code on every pass through a loop and have to open the pop-up each time.

Overall impressions

IntelliJ IDEA is a good IDE, and I managed to work in it for six months despite these reservations. The experiences in this article are entirely subjective. Other people may be bothered by different things, or not at all, in either IDE. IntelliJ IDEA felt a little cluttered with UI elements and a little less snappy to me. Sometimes it also got overzealous. In a rename refactoring it renamed some unrelated occurrences of a string, and I didn't notice at all. Those six months were worthwhile. I learned a new IDE and found I could work in it without major problems. The longer I spent in it, though, the more I felt it gave me little over Eclipse. I made a real effort to learn the keyboard shortcuts that might speed up my work. I eventually realized my way of working was shaped by Eclipse and simply isn't as efficient in IntelliJ IDEA.

Throughout the article I've been referring to IntelliJ IDEA 13, which I used through the Early Access Program. For the record, downloading artifacts from a Maven repository that requires SNI over HTTPS doesn't work in IntelliJ IDEA either.