Eclipse vs IDEA

After having been a hardcore Eclipse fan for over 10 years, I made the switch to IntelliJ IDEA last year. I used to be completely satisfied with Eclipse. Infact, I never imagined I could ever get comfortable with another IDE for the rest of my life.

Come join me as I take you through my journey.

A little bit of history

In 2004, as a newcomer to the software development world, I had been using lightweight text editors such as EditPlus and JCreator.

My love for Eclipse started when I was introduced to it professionally yet indirectly through what was then known as WSAD (WebSphere Application Developer).

Ctrl + Space was godsend!

Just typing the name of a variable followed by . and watching the IDE magically suggest a list of all available methods was sheer joy.

Anyway, that’s how my first exposure to Eclipse happened. In the next few years, I also tried NetBeans, another top contender at that time and loathed it immediately. As is typical of any IBM product, the tool soon started to feel heavy as more and more features were added in the coming years. They even renamed WSAD to RAD (Rational Application Developer) which was such a CPU and memory hog that I had to find an alternative — one that made sure I didn’t have to forego my muscle memory of keyboard shortcuts.

Incidentally, Eclipse had just been open sourced and I was quick to latch on to it. It offered me all that I wanted. It was a rather lightweight IDE using which I could do virtually everything I had learnt until then and yet had my favourite keyboard shortcuts.

My contribution to the Eclipse community

I was so enamoured by Eclipse that I soon started to look inside its source code. I was eager to give something back to the community and was always looking for opportunities.

Thankfully, I did not have to wait too long.

One day, I realised how hard it was to hand code toString() implementation for Java beans (POJO – trust me I still hate this acronym). We had to painstakingly type the name, value and separators for each field of every class and had to also make sure the output looked well formatted.

It would’ve looked something like this.

 * Constructs a <code>String</code>with all attributes
 * in name = value format.
 * @return a <code>String</code> representation
 * of this object.
public String toString() {
    final String TAB = "    ";
    String retValue = "";

    retValue = "Person ( "
        + super.toString() + TAB
        + "name = " + + TAB
        + "age = " + this.age + TAB
        + " )";

    return retValue;

You should remember that this was in ~2005 when using too much Java reflection was frowned upon. So, helpers such as ReflectionToStringBuilder were considered evil and ruled out.

I started think on the lines of a code generation plugin for Eclipse. I envisaged it being as simple/intuitive as just having to right-click on a class and clicking Generate toString().

It was very hard to find good documentation on various aspects of Eclipse plugin development. I had to decompile some existing plugins to understand things.

Enter JUtils toString Generator.

I know, not a very fashionable name but the plugin did the job. I even received a few awards and accolades for my work. I gained some fame too at work.

More importantly, I was very excited to see my plugin website appearing on the top of Google search results for “adarsh eclipse”.

After a few years, I lost interest in further development of the plugin. The final nail in the coffin was Eclipse adding a feature to generate toString(), out-of-the-box. I was astonished as to how similar their solution was compared to mine. Perhaps it’s not so surprising as during its hay day, my plugin was the most popular toString generator out there, being downloaded up to 30 times every day.

Where it all started to wither

My deep appreciation for Eclipse persisted for another 9 years. Various technologies and trends had come and gone, including EJB, JSP and Servlets, XML, Struts, JSF, Hibernate, Java 5, JUnit, JSON, TestNG, Spring, Spring MVC, Maven and more.

Eclipse usually coped well with most of these technologies. Where it could not, there were always plugins available. A few indispensable ones I can remember off the top of my head include MoreUnit, M2 Eclipse, WTP plugin for web development, STS for Spring support and so on.

Unfortunately installing multiple plugins made Eclipse slow and often this could have been circumvented by tweaking the VM options. A more serious annoyance though was having to deal with various quirks of the many third party plugins. For instance, who can’t remember the nearly unsolvable “Missing M2E Connectors” error?

Missing m2e connectors error

Maven POM file showing errors in Eclipse.

Or the strange times when Eclipse just cannot attach the source code for a piece of code that you are debugging. (The only viable alternative is to perform remote debugging).

Source not found

Eclipse debugger fails to attach source code for a simple Spring MVC controller.

In all, there were (and still are) a few such pesky areas but I was quite content with Eclipse in general. Perhaps because I did not know better at the time or I was afraid of change.

Either way, I had been Eclipsed.

The final blow

In 2013, I started a new job. This job was different in many ways. For the first time, I was not going to be programming in Java. Groovy was the chosen language. I was also going to be pair programming full time.

Due to better tooling support for Groovy and Grails, the team had already been using IntelliJ IDEA. Also, pair programming meant that anyone could work on any available workstation. Because of this, all the machines in the team had to be consistent, running the same operating system, IDE and so on.

All this only meant that I had no choice but to switch to IntelliJ.

My first tryst with IntelliJ IDEA

It was my first day of pairing at my new job. I had to open a project related Groovy file. My muscle memory kicked in and I issued Ctrl + Shift + R almost involuntarily. To my dismay a “Replace in Path” dialogue popped up. I shrugged and wondered what was going on.

Replace in Path

IntelliJ IDEA pops up a Replace in Path dialogue for Ctrl + Shift + R

My pair chuckled and told me that the shortcut for opening a file would be Ctrl + Shift + N on IntelliJ.

I knew straightaway that it was going to be very hard for me to get used to IntelliJ.

Few other highly unintuitive shortcuts I discovered that day include:

  • Ctrl + N for opening a class rather than the standard “create new” of something.
  • Ctrl + W for selecting a word instead of closing a tab.
  • Ctrl + Alt + L for formatting code that conflicts with Ubuntu’s shortcut for locking the machine.

My most favourite one, the formidable Ctrl + Space was now called Alt + Enter.

My world had suddenly been turned upside down.


Yes, that was the term used – by my previously Eclipse using colleagues – to reassure me that I would soon get used to working on IntelliJ and that I was going to love it.

However, one unanimous complaint they seemed to have against Eclipse was that it crashed very often, an argument that I have always disagreed. Eclipse is a very powerful tool and if you know where to tweak things, you would never run into stability issues.

During this phase which lasted several months, I continued using Eclipse at home for my personal projects (including building this website) and IntelliJ at work. You could imagine my brain having a split over the diametrically different shortcuts. But I coped quite well and was soon switching the keymaps in my mind seamlessly.

All those months, I was critically noting down areas where IntelliJ fared better and ones where Eclipse did. I hated to admit, IntelliJ was winning.

The final switch to IntelliJ

One day I decided to give IntelliJ a go for one of my home projects which used Maven, Java and Spring. I cloned the Git repository into a directory, selected “Import Project” in IntelliJ and clicked through to finish.

The IDE went momentarily busy and it was ready for action.

No Maven errors, JSP errors, issues with Spring or anything of that sort. To be doubly sure, I ran all the tests and they ran happily.

I tried running the application and several Maven dependencies were downloaded and soon the embedded Tomcat fired on. The application was simply running!

The acid test for me was being able to debug and stop at breakpoints where Eclipse would’ve failed. So, I set a few breakpoints in the controller code and a transactional service class (which would’ve been proxied at runtime). After restarting the application in debug mode, all my breakpoints were honoured.

I was a very happy bunny at this stage.


I have started to realise how much of a struggle it had been with Eclipse.

Setting projects up is generally a breeze in IntelliJ. Most of the times, it just works, never coming in the way of the busy developer. If nothing works, there is always the “Invalidate caches and restart” option.

I never had to install third party plugins such as MoreUnit to jump between main and test code; the IDE did this out of the box, although they chose a very bad keyboard shortcut.

Integration with Git was quite extraordinary. Again, all this was accomplished in-product.

With the release of IntelliJ IDEA 13 Ultimate Edition, even more things were possible. The main highlight for me being the multiple cursors.

I soon abandoned Eclipse, got myself an IntelliJ IDEA Ultimate licence and started using it for all my home projects too.

What about Eclipse?

Though I am a happy customer of IntelliJ, there are some areas in which Eclipse shines through.

Take keyboard shortcuts for instance. The ones used by Eclipse are highly intuitive, leading to virtually no learning curve.

Even more importantly, Eclipse is free software helping everyone from students to non-profit organisations. IntelliJ too has a community edition these days but it is a far cry from the fully loaded Ultimate Edition.


comments powered by Disqus