• Home
  • Events
  • About
  • IntelliJ IDEA X for Groovy Developers

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks


    1. Dierk König said,

      December 20, 2010 @ 11:55

      My preferrred one: Ctrl-Shift-I for “show implementation”. Put the cursor onto a reference, hit the keys, and the implementation shows up in a tooltip. No more back-and-forth navigation.

    2. Mike Miller said,

      December 20, 2010 @ 14:39

      New version is nice but Community version still does not include Grails support.

    3. Hamlet said,

      December 20, 2010 @ 14:42

      That’s worth noting. Everything here is in the community edition, everything Grails related is in the Ultimate Edition. I have absolutely no insider information on this, but I can’t image the community edition getting Grails support any time soon. You never know though, the open sourcing of the CE took me by total surprise.

    4. dotnetnewbie44 said,

      December 21, 2010 @ 22:03


      You seem to be a seasoned hat with IntelliJ & Groovy – what practices do you take to deal with unresolved references in Groovy & IntelliJ? I’ve actually posted in the IDEA community discussion http://devnet.jetbrains.net/thread/292731 and am going to try Groovy++ shortly.

      I’m currently doing a sizable refactor on a codebase where tests aren’t that great, and so far the best tool I found is changing my inspections to error on unresolved — but it’s a slow process; much slower than if I got compiler warnings etc.

      But maybe you have some tips too?

      PS – I really liked your summary of new features; makes me want to upgrade asap

    5. Hamlet said,

      December 22, 2010 @ 8:01

      @dotnetnewbie44 – Groovy is a dynamic language. There will always be times where a variable cannot be resolved and that is perfectly OK at compile time. Your forum post says you’re considering Groovy++, but that is not always a drop in replacement for Groovy. It is a slightly different language with slightly different semantics than Groovy. If you do not have test coverage on your code, then I think swapping out Groovy for Groovy++ is a bad idea because there will be differences in behavior at runtime. It is like trying to swap out Java for Groovy… yes it is possible, but there are different semantics in the language. I would be scared to do this myself without an extensive battery of tests.

      As for unresolved references… you’re making a big refactoring without tests. My advice is to spend some time writing high level acceptance tests that run before and after, then make the refactoring. Sorry, that may not be what you want to hear.

    6. dotnetnewbie44 said,

      December 22, 2010 @ 15:53

      Hamlet – thanks…I was just looking for I don’t have any tips! 😉 I’m aware of the things you are saying, but one cannot control what one inherits.

      Personally, I think this is a problem that is begging to be solved. Imagine if you can have static type compilation & checking & refactor goodness on a dynamic language? There’s a gap in the market for someone who is a can do as opposed to cannot do

    RSS feed for comments on this post · TrackBack URI

    Leave a Comment

    Time limit is exhausted. Please reload the CAPTCHA.