Considering IntelliJ for Eclipse Users

From Aventine Solutions

Jump to: navigation, search

For veteran users of Eclipse, trying out IntelliJ is a daunting task, I found. If you Google something like compare intellij eclipse or differences intellij eclipse, you see a lot of ranting and flaming between the two camps and not a lot of good information to help out in your evaluation. But, since Martin Fowler's ThoughtWorks folk, plus some colleagues in Germany that I trust, have chosen IntelliJ over Eclipse, I am determined to go forward on this.

So, what are the important considerations for dumping Eclipse in favor of IntelliJ? Here are mine:

  1. Are IntelliJ Java projects faster especially when scaling up to large ones? A persistant complaint about Eclipse is that it seems to really bog down and/or crash with very big projects (and lots of plug-in installed). This is a difficult and time-consuming thing to prove scientifically and concretely, so my intuition will mostly come into play here.
  2. How do the two compare handling Ruby and Ruby on Rails? (IntelliJ has recently advertised itself as a good Rails IDE). I will tackle this evaluation in a separate, future, article.
  3. My favorite Eclipse plug-ins ... is there any functionality not covered by IntelliJ functionality and plug-ins? For instance, I've gotten very used to the rich functionality of the Oxygen XML plug-in and have come to dislike Eclipse's built-in XML editor. And, as you'd expect, the Oxygen people don't have both an Eclipse and an IntelliJ plug-in to offer (who would bother?).
  4. Refactoring support. IntelliJ users claim refactoring is better supported than in Eclipse.
  5. Managing test cases and suites. These days an IDE better be good at helping the developer do test-driven development. (This is especially true for Ruby where those folk rely heavily on TDD rather than the strong typing that is the foundation of Java.)


[edit] Before you read further

Before continuing on my article, please read this highly informitive look at the top Java IDE's by Jacek Furmankiewicz. If you are, especially, working on Swing projects, you might want to strongly consider Net Beans instead of either Eclipse or IntelliJ:

[edit] Introducing IntelliJ to your Eclipse Projects

About Idea IntelliJ 7

  • The first, most important hint is that an Eclipse workspace is equal to an IntelliJ project and further, that an Eclipse project is equal to an IntelliJ module. Get this concept in your head or you will start out screwing up your IntelliJ workspace from the beginning (I had several false starts). If you open the IntelliJ help and search for Eclipse, you'll find a handy short page on the difference in terminology between the two.
  • It seems that it would make sense to keep your IntelliJ project space linked with your Eclipse workspace, especially when evaluating the former. Changes from IntelliJ will be propageted to the Eclipse workspace I assume. I have checked in the projects on the Eclipse-side into Subversion and IntelliJ picks all this up.


  • IntelliJ also correctly turns the Eclipse projects into IntelliJ modules in it's own workwpace, but incorrectly assumes that the default module type is Java. In my case, most of the projects in my Eclipse workpsace were actually non-Java projects, because 1) I use Eclipse a lot as a client for Subversion and 2) I am most interested right now in trying out Ruby and Rails on IntelliJ. The actual sandbox files in Subversion stay in the Eclipse directory.
  • The IntelliJ equivalent of the Eclipse .project file is an IML file, where, for lack of information found in the Eclipse properties, IntelliJ has assumed a Java nature. This points out a more core difference between the two: Eclipse can be installed as a naked IDE without any preference for Java. In fact, there is a default type of project, Simple Project which can be used just to set-up a folder structure in the workspace and decide what natures it will have later. On the other hand, IntelliJ shows clearly that it is meant primarily as a Java IDE since this is the default nature and there is no equivalent vanilla type to select.
  • On the Macintosh, a default JDK was not detected, therefore I had to add at least one version of the JDK manually (maybe this is different on Windows or Linux?).

[edit] A Short Eclipse to IntelliJ Dictionary

[edit] Remarkable Differences

  • IntelliJ does not seem to have a build automatically as does Eclipse; instead you must explicitly (re)build your current file or the whole project, where, by default, a dialog box pops-up and must be sent to the background, if desired. My experience on Eclipse teams is that everyone has their projects building automatically with the result being that a progress bar on the bottom is showing constant compiling activity as you code along. This is a big difference in working style, I think.
  • IntelliJ automatically detects a Spring configured project and inspects the configuration XML files when a build is done. Spring configuration is also part of code inspection to assist in potential problems and bugs in this area.
  • By default, Eclipse requires manually loading of changes to files done outside of the IDE, while IntelliJ picks up external changes immediately. This is useful if you wants to run both IDE's at the same time to compare editors and code formatting. Eclipse can be set to automatically refresh the workspace, but this can cause crashing when using Maven to configure your Eclipse workspace and the refresh happens while running the Maven goal.
  • Out of the box, IntelliJ does not help with generating a JUnit test from an existing class or interface as does Eclipse. A plug-in has to be installed and one of them, JUnit 4 Sychronizer is not compatible with version 7. I found this missing feature a big surprise for IntelliJ.
  • Code templates in IntelliJ are called up with a separate command (command-J on the Mac) whereas Eclipse calls them up in the same list as code completion, but visually marks them as templates. However, the live template concept in IntelliJ is much more flexible in that variable supstitution can be controlled in a very granular way and a special type of template, surround templates, can be applied to pre-selected blocks of text. IntelliJ comes with much more templates out of the box including ones, for example, for Spring XML configurations.
  • The start-up of my JUnit tests (Spring injected) in IntelliJ always take longer than in Eclipse. This was true for both a normal run and running them in the debugger. This has something to do with it swallowing the console output and caching it to display later, which gives the idea at first that the whole thing is frozen or has crashed. In no time, the IDE ran of memory running tests, asking that I shut everything down and increase the Xmx setting in the JVM. Image:Screenshot-intellij-out-of-memory.png The test that caused this error in IntelliJ runs perfectly fine in Eclipse, giving me console output right away to feel satisfied that I'm getting some work done.

[edit] IntelliJ Niceties

  • If you hold the command key while using the mouse scroll-wheel while focused in the editor, you can increase and decrease the size of the font, essentially zooming in and out. A nicety for us seniors going blind.
  • You get productivity hints when long processes cause the progress bar to pop-up. This of course can be turned of if you don't like it. Image:Screenshot-intellij-productivity-hint-while-compiling.png
  • From the start, IntelliJ is intelligent about your Spring injected project. The Spring context is inspected to help you avoid bugs and improve the quality of the XML coding. While editing Spring configurations, the editor can find the getters and setters of the classes to be injected and help you with code completion. Also code completion works for beans within the context that refer to other beans.
  • Likewise for Maven. IntelliJ has tools for managing and running your Maven goals and configurations. Eclipse does not have this out-of-the-box, but there are probably plug-ins available. (Both IDE's base installations come with Ant support, however.)
  • Go To File (ctrl-shift-N on Mac). This is a handy pop-up to quickly search for non-Java files in the project scope and open their editor.Image:Screenshot-intellij-gotofile.png
  • JetConnect: a built-in blog reader which gives you the latest news and IDE productivity tips from JetBrains. Excellent! Image:Screenshot-intellij-jetconnect.png

[edit] Code Completion Frustration

IntelliJ has more than one type of code completion (something a seasoned Java IDE user takes advantage all the time without a nano-second of hesitation; a huge productivity booster). In Eclipse, code completion can be called up using ctrl-space and it finds the class I'm looking for Image:Screenshot-eclipse-codecomplete-classname.png. If I back up and do exactly the same in IntelliJ, also using ctrl-space, it only offers no suggestions Image:Screenshot-intellij-codecompletion-nosuggestion.png.

The difference is that this default keymapping in IntelliJ is for basic code completion whereas the equivalent for Eclipse would be class name completion.

I find the different types of code completion in IntelliJ a productivity killer, because you have to think ahead what you want and choose the correct command. Eclipse combines the completion of local variable names, methods calls, static class members, class names not yet imported and templates all into one sort of code completion and marks the types with different icons in the pop-up. Also, the class completion in IntelliJ has an awkward latency in calling up the list of possiblities compared to Eclipse.

To avoid frustration (but not totally solve this problem), try switching the key mappings between the two:

  • map ctrl-space to the menu command Code -> Complete Code -> Class Name
  • map ctrl-alt-space to the menu command Code -> Complete Code -> Basic


[edit] Smaller, but Annoying Differences

  • IntelliJ does not seem capable of restarting itself when changes are made to plug-ins (installing/uninstalling or even enabling/disabling) whereas Eclipse usually can.
  • Pasting code from one file to another causes the imports in Eclipse to automatically get pasted as well, IntelliJ requires you to confirm that you want to do this.
  • There a literally hundreds of user interface differences, to be expected, that will make you want to scream. Some things that are a simple keystoke plus a click away in one editor is a pop-up dialog in another. Some things that you use frequently are nicely situated in top level menus while others are buried under layers of sub-menus. Things that are a breeze in one are an arduous task in another with lot's of backing up and deleting. The level of frustration you will feel, IMHO, is directly related to how long you've worked with Eclipse. If you are a relative newbie to Eclipse and remain basically unimpressed or unexcited, then IntelliJ will seem slick, friendly, coaxing and refreshing. If, on the other hand, you have been working with Eclipse since it's early days, you will have to resist the urges to throw your workstation out the window and head to the local pub. This makes the choice to migrate to IntelliJ very difficult, because your productivity will grind to a halt as you grapple with these differences. Is there really enough of a return on investment to do so in this case? On the other hand, have you bent your style of working to the inadequacies of Eclipse and need to streamline your working patterns with IntelliJ with just a little investment of time plus a pinch of frustration?

[edit] Conclusion

After a few weeks of struggling with this, I have to recommend against IntelliJ for established Eclipse users.

In fairness to IntelliJ, it could have been the combination of my current projects, my busy work schedule and bogged down workstation resources when trying to run the two different IDE's with other developer's tools and server processes which lead me to really hating this experience. Running VMWare to get a personal copy of Microsoft SQL Server databases running on a Macintosh is decidedly a resource hog of itself.

I was constantly frustrated trying to get even the simplest things done in IntelliJ and when the second 30-day evaluation period was up, I had to honestly ask myself if I really wanted to shell out around US$176 for a personal copy that simply prolongs my pain while absolutely no one around me uses it.

If you are already using Eclipse and occasionally annoyed when it crashes, then just stick with it because the cost of switching over to IntelliJ is just too high (I mean, the human cost of a steep learning curve and hitting the brakes on productivity). If you keep adding modules to your Eclipse workspace and find you are running out of resources, maybe the simple, cheaper solution is to buy a new machine with more memory and a faster CPU (plus this might placate the Greedy Gadget Geek inside you for awhile).

If you are shopping around for Java IDE's, then it makes sense to consider IntelliJ and, for that matter, Net Beans depending on what type of Java projects you will be working on and which frameworks you'll be using.

As I said above, some day, after I've recovered from this, I'll get another evaulation copy of IntelliJ and try out a Ruby on Rails project with it.

[edit] Appendix: Environment and Software Versions Used for this Evaluation

Was this an unbiased, scientific evaluation in a scientifically controlled environment? Absolutely not. I fit it in with the current project I was working on, the evaluation was spread out over several weeks as I did ny normal design and coding tasks with the team. Take it or leave it.

The project was a J2EE architected web services bus application and I worked on the data warehouse and ETL components using open source solutions where possible. The team was around a dozen developers all using Eclipse, two of which were on Macintoshes and the rest on Windows XPPro. Here are the tools and software I used:

workstationApple MacBookPro with MacOSX Tiger 10.3
IntelliJ7.0.1 Build 7364
VMWare Fusion
Microsoft SQL Serveron VMWare
Java frameworksClover ETL, iBatis, Spring, Axis, Mule
Personal tools