Skip to main content

4 reasons to move to IntelliJ and bail on Eclipse

  1. Same JAR, different version. If you have multiple projects in your workspace depend on different versions of the same JAR, Eclipse will hand out all of them the same version, which is the one it happened to load first. Uncool. IntelliJ handles this case properly.
  2. Spring support. IntelliJ is capable of certain tractability between your Java and your spring XML context. For instance, if you refactor a class name, its bean will be renamed accordingly. You can also navigate from your Java class name to its corresponding spring bean. How cool is that?
  3. Static imports. Because I simply hated looking for the proper import for every Hamcrest static mather I needed. IntelliJ suggests to add them for you.
  4. Out of the box SVN integration. IntelliJ supports SVN right out of the box, no need to download any SVN plugins or tweak any configuration files. Not a biggy, but it's nice nonetheless.

I guess one does have to mention Eclipse's incredible and unmatched plugin repository, and some would argue its background compilation mechanism works better at the moment. In addition, IntelliJ tends to go into an intense processing phase that pretty much grinds things to a halt for a minute or two every time you update your code. Everyone has their quirks. 

However, when it comes down to the overall experience, with Eclipse it often feels like I'm fighting the IDE to get things done, with IntelliJ it feels like it just gets me. 

IntelliJ, you auto-complete me.



Comments

Popular posts from this blog

Sending out Storm metrics

There are a few posts talking about Storm's metrics mechanism, among which you can find Michael Noll's postJason Trost's post and the storm-metrics-statsd github project, and last but not least (or is it?)  Storm's documentation.

While all of the above provide a decent amount of information, and one is definitely encouraged to read them all before proceeding, it feels like in order to get the full picture one needs to combine them all, and even then a few bits and pieces are left missing. It is these missing bits I'll be rambling about in this post.

Dependency Injection - The good, the bad and the ugly

The Good
Dependency injection (DI, a.k.a IoC - inversion of control) is a well known technique to increase software modularity by reducing coupling between modules. To provide the benefits of DI, numerous DI frameworks have arisen (Spring, Guice, Castle Windsor, etc.) all of which essentially give you "DI capabilities" right out of the box (these frameworks tend to provide a whole lot more than just "DI capabilities", but that's not really relevant to the point I'm about to make). Now, to remove the quotes around "DI capabilities", let's define it as a DI container - a sack of objects you can manipulate using a provided API in order to wire these objects together into an object graph that makes up your application.

I've worked on quite a few projects employing Spring, so it will be my framework of reference throughout the rest of the post, but the principles and morals apply just the same.