GGTS vs. IntelliJ IDEA

For years, I’ve been hearing about the superiority of IntelliJ over Eclipse from its enthusiastic fan base. However, I couldn’t find any evidence to persuade me to switch. I’ve had my frustrations with Eclipse, to be sure. I’d love to find a great replacement for any of my tools. But nobody could give me a clear reason. From its fans, I heard, “It’s just better.” Same endorsement I hear for OS X. And JetBrains’ feature list doesn’t having anything over GGTS. I needed a real reason to switch.

Well, earlier this month I got one. I won an IntelliJ Ultimate license at an LAJUG raffle. I now agree that IntelliJ is better, and I have clear reasons why!

The folks at JetBrains have always had a reputation at being language gurus. They’ve been able to provide support for languages faster than others, and frequently more comprehensively, even for dynamic languages. They’ve even invented a language. While I knew this, I assumed that for Java and Groovy GGTS would be on par due to it’s heritage. Unfortunately, it’s not.

To give you a clear example, I recently generated static scaffolding for a domain class in Grails 2.3. I noticed the controller uses the respond method instead of render, and the respond docs are not comprehensive. I tried opening the declaration to look at the code and it doesn’t work – GGTS has no idea where the code for controller methods reside.

I also tried some static imports of an embedded enum and again, GGTS had issues. Autocomplete (ctrl-space) didn’t work, nor did highlighting. In other parts of the code, it couldn’t locate the declaration for classes where a dynamic finder (e.g., User.findAllByName) was being invoked! In some classes it did work, but overall it was inconsistent. To be clear, there were neither compilation nor runtime errors – the code was fine, and to be honest there wasn’t much of it. This is a pretty new project.

As a test, I decided to import it into IntelliJ. The first attempt failed. I had it import it from Git, then parse the Eclipse project file when that was offered as an option. I was close to giving up as it didn’t even seem to recognize it as a Grails project, and there was no clear way to fix it in the configuration. But instead of giving up, I deleted the project and reimported it, this time ignoring the .project files and letting it discover the Grails nature on it’s own. Much better!

I opened the troublesome controller and noticed everything was properly highlighted, including those pesky enums. It understood the code and could open the declaration of all the classes, even those using a finder (and autocomplete was pretty nice). But best of all, it had no problem opening the declaration of those Grails controller methods like respond and render! This is a big win and clear advantage over GGTS.

I then checked out running/debugging. I’m a big fan of the debugger and had heard that IntelliJ’s method involves attaching to a separately run/managed Tomcat instance. This may have been the case in the past, but I was able to run and debug my Grails app the same way I do with GGTS – right from the IDE with “run-app -https”. No extra hoops to jump through.

Couple things I wish were better with IntelliJ:

  • Key bindings are not mnemonic. I’m sure they can be updated, but the choices strike me as odd.
  • Help window usability is bad, which is odd considering overall usability is good. Examples:
    • mouse scrolling is page-up/down, not smooth scrolling
    • searching highlights phrase – but you can’t turn it off!
    • back/forward buttons have no effect

Considering that help pages are the last refuge of the hopeless, making that a good experience is really important to customer satisfaction.

Couple tips for Eclipse/GGTS/STS users:

  • Search for “CamelHumps” in settings to navigate camel case like Eclipse
  • Play around with the Groovy/Java code style, in particular indentation, to match what you’re used to.


Optimal JVM settings for STS/GGTS

I recently switched from Eclipse 3.6 to STS 2.7.1 (based on Eclipse 3.7). Ditching my old .project and workspace settings files along with the move has made for a smoother experience; it seems these files get corrupted over time,1 and I’m too lazy to do the research to fix them. However, the upgrade resulted in performance issues. For instance, it hung for ~10 seconds every time I saved web.xml, and there were various random pauses. It’s not the hardware: I’m on a Core i7 Quad with 6GB RAM running Win7 x64. I realize you are getting more tooling with STS, but performance was much worse than I experienced with 3.6.

Well, it had slipped my mind that I had updated my 3.6 eclipse.ini settings with those I had found in an excellent Stack Overflow answer from VonC on optimal JVM settings for Eclipse. It hasn’t been updated for 3.7 (nor does it mention STS), but after some experimenting and research it appears to work well for it. Here are my settings, and below I add some commentary on what they do, which is missing from the original answer (although I still suggest you read that, as it covers other situations/issues that may affect you). Keep in mind I’m not a JVM tuning expert, YMMV, etc. Here are the contents of my sts.ini:


This is the number of method invocations/branches before compiling. This is normally set to 10,000, so we’re changing it dramatically, but the original suggestion was leading to errors so I raised it. You will notice on startup that it takes longer, and your CPU usage jumps. However, your performance after that is much better. Those 10s save times for web.xml? Gone after this. I’m willing to take a hit at the beginning for better productivity while coding.

Related to the above, I was getting the error “Unhandled event loop exception / out of space in CodeCache for adapters” due to setting the compile threshold to 5. This is another solution to that problem, and may be redundant.

This is stack size, and was previously set to 1MB, now up to 4MB per thread. Doing this will increase the overall memory used.


These enable parallel garbage collection. I saw my CPU utilization reach 100% after this, which is rare on a Core i7 Quad. It felt like I was finally using it to its potential.

Again, I’m not an expert. I’ve found it’s more sluggish at first, but response times quickly improve. For me, it’s a clear net gain. Not documented are the things I turned off in preferences because I wasn’t using them (Maven is disconnected, etc.). Visit Windows >> Preferences and filter on startup, see if there’s anything you can get rid of. Finally, I must give credit to my sources outside the original article:

  1. I’ve had issues with things like web deployment assemblies, not prompting for workspace on startup, etc. []

Deleting (undeletable) Tasks In Eclipse

I recently had some more frustration with Eclipse, with no solution on the web, so I’m posting mine.

The problem:

I had an auto-generated task (TODO) from creating a class that implemented an interface. At some point, I noticed the task comment was gone, but the task indicator (checkbox icon) was still there. Probably because I have it set to reformat on save, but maybe I deleted the task comment without hitting the task button (or both). Anyway, I could not clear it no matter what:

  • Double clicking the icon didn’t work since it couldn’t find the comment.
  • Clicking the “Clean and Redetect Tasks” button did nothing.
  • Restarting Eclipse (which I do more often than a Windows admin reboots), did naught.
  • The Task View displayed the offending tasks, but the Delete option was greyed out. Selecting the task and hitting delete 3 million times while cursing furiously at the screen brought no justice.

The solution:

  1. Go to Window >> Preferences, then Java/Compiler/Task Tags. Select the TODO task tag, or whatever accursed tag haunts you.
  2. Click Remove. When it threatens a rebuild, call it’s bluff (that is, agree). When it’s done (and it took its sweet time), the offending tasks will be gone. Rejoice!
  3. Click New… and restore the TODO tag. All legitimate TODO tasks will be restored.  Callooh! Callay!

keywords: can’t delete tasks, task tags, eclipse 3.4, mylyn

Eclipse “cannot be resolved to a type” error

So I’m coding along and all of a sudden, Eclipse (3.4) can’t resolve classes. Classes that are in the same package as the class I’m editing. Classes that are fully qualified in the import statement.

Not good.

The last thing I had done was add a Spring @Autowired annotation. I saved the file and voila, everything goes to crap. I then spend a stupid amount of time trying to track down the cause. I took the changes out. I did a clean and rebuild and retest (everything passed; this was Eclipse-only). I added new classes to see if they broke (they did). I did a false modify (add space, remove space, save) to see if that broke said file (it did). It was a death spiral. No matter how I changed the code, the same problem was there.

Turns out, it wasn’t the annotation, or anything else in Spring, or any of my code, or any of my Eclipse plugins. It was a step before that killed me. I was doing a little cleanup and I created a temp directory at the top of my project folder so I could move some files there. It wasn’t nested in anything, other than the top level directory. What could go wrong?

Apparently, that makes Eclipse see red. Squiggly red.

The solution was simply to do a refresh (F5) on my project. Just as quickly as it started, the problem went away. That smells like a bug to me, but if it was I figure I’d see a lot more mentions in Google or the Eclipse bug tracker. I’m really hoping this helps someone save some time.

Update: If that doesn’t work, try:

Clean, refresh, build, restart

Also, remember any external build/clean scripts you might be using. For instance, Grails has a command line “clean” you may have to invoke. Same if you have Ant or Maven builds.

David Resnick (comment below) discovered this tip for those with an external build script:

Windows–>Preferences–>Java–>Compiler–>Building–>Output folder–>”Rebuild class files modified by others”.

This exists in Eclipse 3.5; I’m not sure about earlier versions.

Another issue I’ve found over the years is problems when upgrading Eclipse. In theory, new versions of Eclipse should update your workspace and project files just fine. In practice, they can become corrupted. My new rule is to create a new workspace for every major version upgrade of Eclipse (maybe more often if you’re cautious). Then I copy those projects and import the copy. This ensures I have a backup plan should something go awry. You may need to reimport your project(s) if there’s a problem that won’t go away after an upgrade.

Many commenters offered other solutions, so check below. Thanks to those who contributed them!

Update: I switched to IntelliJ. Click that link for details why, it’s not the usual hand-wavy “it’s just so much better” that never got me to switch. Not saying it’s bug free, but nothing is, and I’ve never seen errors like this there.

Keywords: false error, bogus error, eclipse bug