Uncategorized

Why I’m not using Groovy at work

Posted on December 14, 2009. Filed under: Grails, Groovy, Uncategorized | Tags: , , |

A disclaimer: this blog is based on my personal failures with getting Grails accepted in our company. So, no, this is not the holy grail into dropping your EJB, Struts or Java toolkit to get groovy with Grails, but maybe you can learn something on how NOT to do it, and post some comments on your experience.

Introduction
2.5 Years ago, I got my first cup of Grails. It was some time before the Groovy/Grails Exchange 2007, which I visited consecutively. As a result of that visit, I had Graeme Rocher over to our company to give a presentation about Grails (almost 0.4 at that time), and I expected the rest to follow naturally (the rest being: drop all our Java development and take up Grails for all of our web development). I was a little naive in that, I experienced the couple of months after that. Not even did we not drop all our Java development: we dropped none, nor did we picked up any of the cool features Groovy or Grails offered. Instead, people went crazy with frameworks like Wicket, SEAM and other cool stuff, like..ehh…EJB’s…

However, in my spare time I never left Grails and I used it for a lot of prototype applications, especially because the ease of setting up a complete project with Spring/Hibernate integration, etc. And also because it’s just fun to use the power the Grails framework harnesses. Anyway, I never could convince people to seriously use it. I inspired some people to use it, but only for short periods. The lack of IDE support didn’t help in that, and with the thousands of frameworks around, you’ve got to make a choice somewhere. However, I haven’t given up on Grails, and I still try to use it as much as possible. So, when I started for myself in April as an independent (though I do favor certain technologies!) consultant, I thought: this is my chance! I can now focus on Grails technologies. However, even though I’m not quite inexperienced with Grails, I found it hard to find a good (well, any actually) project which was open to Grails, so I found a different project, in which I could focus on other things (like ATDD/TDD, XP, and other quality related things).

However, then, all of a sudden my manager showed some interest in Grails (might not be the best reason to use Grails btw, but it’s great that this is without any resistance!), and we decided to take on a project in Grails. There, the problems started. (Note: I don’t blame anyone in this, except myself: I should have used a different approach. That’s part of reason for writing this blog, to prevent you from making the same mistakes).

What I did first, was tell a little bit about Grails to explain the team how Grails works. That was actually my first mistake. I should have told them lots, lots, a little more, and everything again after that. I thought the transition would be easy, but they were struggling with the framework and the language. I didn’t expect this, to be honest. My expectation (and experience) is that Grails is easy to start with. Get a book, read the documentation, and your ready to go. We built a good prototype, got great feedback on it! However, the old habit kicked in.

Building Grails
First, we tried to build our Grails application with Maven. Bad idea, since it caused some nasty challenges, like getting the code coverage to appear, and getting come quality metrics with tools like CodeNarc. However, you’ll still have to do your (transitive?) dependency management, releasing of software, reports, etc, so there’s something to say for using Maven. It didn’t quite work for us, however, and we spent quite some time into bending it into something which worked for us, which failed. I still haven’t found a viable alternative to Maven. Gradle is nice, Ivy + Ant/Gant seem okay, but that’s not nowhere near the power (I wouldn’t say flexibility) I got with using Maven. I do not, however, make this a Maven vs Whatever Build Tool discussion. I just happen to like Maven for it’s reports, plugin integration, dependency support and modular structure.

Team
Then I also had to overcome the resistance of some of our team members to dynamic languages. Some people prefer the (fake, IMO) safety a statically typed language provides with it’s compilation process. Well, there’s no helping you if you do an Integer.parseInt(“abc”) in your Java code: it will fail just as badly. At runtime. That’s why we write tests, to cover cases like this. This is true for Java, and it’s just as true for Groovy. However, there was still a lot of FUD about Groovy’s usage in bigger projects regarding refactoring, tool support, and even performance. Well, to be honest: I have no idea how easy it is to refactor Groovy code, but, with less code to write, there’s less to refactor. While this might be a bit short sighted, I feel it holds true for a lot of cases.

IDE
The tool support deserves a paragraph on it’s own. Eclipse + Groovy was not a good combination. At all. It was bad, worse, and even a bit worse than that. Even if you are the genius to get it to work (or would I say madmen, since a genius would choose a tool like NetBean or IntelliJ, or, heck, TextMate), you still wouldn’t be able to run a decent unit test in it. Did I mention refactoring? I didn’t, for a good reason: No Support For Refactoring. Let me rephrase that: No Support For Refactoring… in Eclipse. Then why choose Eclipse, and not a great tool like IntelliJ (I’m referring to the 8 release) or NetBeans you might ask. To be honest: I have no idea. I don’t use Eclipse. I’ve used IntelliJ for the last 5 years, and only recently I’m switching to SpringSource Tool Suite because of JetBrains’ ridiculous decision to not show module dependencies in the project view. I hope they get some rest after the release of IntelliJ 9, and see the light to put it back in. Until that period, STS is a really good substitute, and has excellent Groovy and Grails support, which is getting better each day!

The right approach?
So, if I would introduce Groovy or Grails again at my work, I would:
– Pick the right people. People who are not intimidated by a dynamic language, but who have the discipline to use it right.
– Pick the right people. People who are prepared to make a switch. To switch from IDE, switch from build tool, switch from language.
– Pick the right people. People who have the mentality to make it work, overcome challenges and share their findings.

Conclusion
It wasn’t intentional to put ‘Pick the right people’ there, but I think that this is the critical factor to make it work. Make it work from within the team, and make it work from outside of the team (IT operations, Management, etc). I’m looking forward into hearing your responses to this. I hope it doesn’t sound to bitter, cause I’m not. I just made the wrong choices with a partially not-suitable team. It’s my mistake, and I don’t blame anyone but me. I just hope people can learn from my experiences, and the post from Marc Palmer was just the right incentive to finish this post. I hope it helps!

Read Full Post | Make a Comment ( 12 so far )

Switching from IntelliJ to SpringSource Tool Suite

Posted on December 6, 2009. Filed under: Uncategorized |

A small disclaimer: I’m a big fan of IntelliJ. In every project I’m on, I use IntelliJ, and it has happened quite often that people get interested in the product, and decide to switch.

However, because of some changes in IntelliJ 9 regarding the non-visibility of module dependencies (a feature any IDE has, including IntelliJ 8), I decided to look for alternatives. Not knowing which dependencies a module has is an unworkable situation for me, since I find quite important to know if my UI module depends on a ORM mapper, or not (in most cases, it should not).

Luckily, there are (quite) some alternatives. I’ve decided to check out SpringSource Tool Suite, because:
a) It integrates with technologies like Spring and Hibernate
b) It has support for Maven, which I use for almost every project
c) It has Groovy and Grails support
d) It’s free. This is not a big deal for me, since I also paid for IntelliJ (and it was worth every euro), but this way, it’s easy to try out.

So I downloaded SpringSource Tool Suite here: http://www.springsource.com/products/sts, and after a quick download (and mount, I’m on MacOS), I was ready to go. I imported the Maven project (File -> Import -> Maven) and I was ready to go.

Wait…what’s this error I’m getting??

“The type PostConstruct is not accessible due to restriction on required library /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar”

Hmm, it seems my project is using an @PostContruct annotation, and for some reason, this is causing problems. Well, after browsing an little through the options, I found this setting, which is the cause of the problem:

SpringSource Tool Suite - Errors / Warnings

This can be found by going to the preferences screen, and then go to Java -> Compiler -> Errors / Warnings, and there you’ll have to set the Forbidden reference access rule to ‘Ignore’ (or warning, but I don’t like the yellow warnings, not for a reason like this anyway)

After setting the option to ignore and rebuilding the project, I good to go, and my project built without any problems!

In short: first impression: nice! I’ll post more about my experiences with SpringSource Tool Suite here in the near future!

Read Full Post | Make a Comment ( 2 so far )

Converting Groovy Objects to JSON using Grails

Posted on February 14, 2009. Filed under: Grails, Groovy, Uncategorized | Tags: , , , |

Disclaimer: this might not be the best way to do it. I’m open for improvements, but it’s a way I’m using now, and it works pretty nice!

Currenly, I’m creating an application which does some JSON communication. Since Grails already has nice support for JSON, I wanted to reuse their libraries, but, at the moment, I don’t need a complete web Grails application. So, the plan was to reuse the JSON (deep) converters to convert my Groovy classes to JSON, and work with that. I created the following small test to try to accomplish what I wanted:


import grails.converters.JSON

class Person {
String name = "erik"
int age = 10
}

println new JSON(new Person()).toString()

Well, I don’t think I’d be writing this blog entry if things were really this easy. Executing the above code fails with a nasty NullPointerException:

Caught: org.apache.commons.lang.UnhandledException: java.lang.NullPointerException
	at testjson.run(testjson.groovy:10)
	at testjson.main(testjson.groovy)

Why is this, you might ask. Well, it turns out the JSON converter is using a ConverterUtil class, which expects a GrailsApplication. When there’s no GrailsApplication, the code will fail with a NPE as a result. If you’d like to see this fixed: I’ve created a JIRA issue here.

However, I did came up with a workaround. It’s not perfect, but it works. Since the ConvertUtil is a sort of Singleton, you call it yourself, and set a DummyGrailsApplication instead. Well, instead of the dummy version, we can use a DefaultGrailsApplication instead. So, after our fix, the code looks like this:


import grails.converters.JSON
import org.codehaus.groovy.grails.commons.DefaultGrailsApplication
import org.codehaus.groovy.grails.web.converters.ConverterUtil

class Person {
String name = "erik"
int age = 10
}
ConverterUtil.getInstance().grailsApplication = new DefaultGrailsApplication()
println new JSON(new Person()).toString()

When running this, the following output is produced:

{"age":10,"class":"Person","name":"erik"}

Which is exactly what we want!

Read Full Post | Make a Comment ( 4 so far )

Liked it here?
Why not try sites on the blogroll...