Tuesday, November 20, 2007

IntelliJ: t3h awesome (mostly)

I installed IntelliJ a couple of weeks ago, and have thus far been impressed. After using Eclipse for the past three years I've been getting more and more annoyed at its sluggishness. I tried NetBeans for about three days, but quickly got frustrated with it. IntelliJ, however, is a lean, mean, fighting machine, intuitive in all the right places and a breeze to use, with a couple of exceptions.

My primary positive praise is all about the speed: IntelliJ is fast. After using the bloated beast that is Eclipse, using IntelliJ makes my neural receptors hum with delight. Loading up and switching between projects is faster. Setting preferences is faster. Tweaking the classpath, refactoring, searching for references, and generating code coverage reports: all faster.

And Groovy? Don't even get me started. The Groovy plug-in for Eclipse is like using a climbing Mt. Everest while drunk: technically possible, but something that will quite likely lead to an early death. The Groovy support in IntelliJ is robust and... fast.

Editing non-Java files is also a breeze. Now, normally I am a vim nut. For years I have been using vim for editing JSPs, XML, config files, etc. Basically, if it's not a Java class, I use vim. I have plenty of macros and various vim-crap to help me along, but IntelliJ is the first thing I have used that has caused me to use vim less -- much to my own surprise. The XML editor is tight: it reads your DTD/schema and lets you do the cmd-space trick for auto-completion of tag names and attributes. Spring configuration files are validated against known classes, so if you reference a bean that IntelliJ doesn't know about, it flags your config file with an error.

Nice.

But all is not roses. We have an extensive Struts application where I work, and the Tiles integration seems to simply be broken. For example, in the following example the input is flagged as an error even though that tile is defined elsewhere:

<action path="/searchPromos" input=".Mpr.Main">

Also, there were problems with the GWT integration that I was unable to overcome. This may simply be due to my inexperience with that framework, so I will not go into detail about that until I am more confident where the blame lays.

There are also two views that Eclipse has that IntelliJ does not: JavaDoc and declaration. I kept these open all the time in Eclipse, and I miss them. The IntelliJ way of viewing JavaDocs is to hit ^j. While this is fine, I still miss my dedicated view.

On the plus side, IntelliJ validates your JavaDocs more thoroughly than Eclipse does. For example, IntelliJ raises a flag in the following due to the discrepancy between what is documented (param) and what is coded (param1):

/**
* A method which does something
*
* @param param
*/
public void doSomething(int param1) { ... }


In any event, IntelliJ is an excellent IDE. It is different from Eclipse, to be sure, but they are kissing cousins. The initial effort I put into it has paid off nicely thus far, and switching has not cause me any undue pain.

1 comment:

Eugenia said...

Hi James!

Mind if we use your kind words for our testimonials? :)

Eugenia
JetBrains, Inc.