Oct 21
Well, quoted at least, in CIO.com’s article “6 Scripting Languages Your Developers Wish You’d Let Them Use.” I just talked Groovy and its Java integration up a bit.
The article itself is okay, the title is a bit misleading, most of the languages that the article visits aren’t really scripting languages as such, but it’s good to see languages like Groovy getting more exposure to the business types.
Anyway, enough self-promotion, back to study. Expect a blog post soon on OpenSearch and Firefox goodness.
Aug 06
Note: I think I’ll re-write this post, it’s a little confusing, but I’m in a rush.
I was just mucking about with threading in Groovy, it really is very simple. You pass Thread.start() a Closure. You could do something as simple as this:
Here’s the sample code I ended up with. There are a few semi-advanced Groovy concepts here.
ReentrantLock.metaClass.withLock allows us to give all ReentrantLock instances a new method called withLock. All this does is wrap a closure (which is called by it() in the middle) with the lock.
We then define a closure called worker, that prints out some spacing depending on which thread is working (the thread number is passed in as a parameter), and some dots, and the relative time (from when we started the program).
After this definition, we actually start 5 threads off, and print “ROCK!”. The curry method is very interesting, if you don’t know what it means, you should read more about currying.
The output of the code is below the sample code.
import java.util.concurrent.locks.ReentrantLock
def startTime = System.currentTimeMillis()
ReentrantLock.metaClass.withLock = {
lock()
try {
it()
}
finally {
unlock()
}
}
def lock = new ReentrantLock()
def worker = { threadNum ->
4.times { count ->
lock.withLock {
print " " * threadNum
print "." * (count + 1)
println " ${System.currentTimeMillis() - startTime}"
}
Thread.sleep(100);
}
}
5.times {
Thread.start worker.curry(it)
}
println "ROCK!"
Output:
ROCK!
. 6
. 6
. 6
. 7
. 8
.. 107
.. 107
.. 108
.. 108
.. 109
... 208
... 208
... 209
... 209
... 210
.... 311
.... 311
.... 312
.... 312
.... 313
Jul 20
I like the simplicity of languages like Ruby and JavaScript. In both of these languages, you can do something similar to:
This actually assigns either bar (if it is truthy), or "default" to foo.
Sadly, with Java and Groovy, foo will actually have either true or false as a value. Behold, there is a way to do the same thing with Groovy:
It’s kind of a play on the ternary operator.
This means I can reduce this code
User currentUser = User.findByName(user)
if (!currentUser) {
currentUser = new User(name: user)
currentUser.save()
}
session.user = currentUser
to the one liner:
session.user = User.findByName(user) ?: new User(name: user).save()
Jul 19
I’ve been working on a pet project in my spare time – a sort of twitter clone that authenticates against Atlassian Crowd. I’m using the awesome Grails/Crowd plugin, which is pretty seamless (but needs a bit of internal polishing).
I’ve only scratched the surface of Grails, but here are a few things I’ve run into as a Grails newb.
Many-to-many relationships and cascading updates
GORM (Grails’s abstraction of Hibernate) lets you define a many-to-many relationship like this:
class User {
String name
static hasMany = [groups: Group]
}
class Group {
String name
static hasMany = [members : User]
static belongsTo = User
}
This relationship can be accessed through some helpful dynamic methods that Grails provides:
new User(name: "foo").addToGroups(name: "bar").save()
//
//
def user = new User(name: "foo").save()
new Group(name: "bar").save().addToMembers(user)
//
//
The crucial part here is the belongsTo property of the domain classes. This tells GORM which class should “own” the relationship. What this means is that if you want the relationship to cascade through both objects, you will need to call the addTo* method on the owning object.
Many-to-many relationships with the same class
Back to the pet project – one of the features I really wanted was the ability to subscribe to status updates for a whole group.
Here’s a quick ERD (generated by the excellent IDEA/Grails integration) of the domain classes:

You can quickly see that there are two many-to-many relationships between the classes User and Group.
The code looks something like this now (other stuff stripped out):
class User {
String name
static hasMany = [groups: Group, groupSubscriptions: Group]
static mappedBy = [groups: "members"]
}
class Group {
String name
static hasMany = [members : User]
static belongsTo = User
static mapping = {
//
table "group_"
}
}
I thought that Grails would be smart enough to see what I was doing, but I was wrong (for various reasons). To cut to the chase, here’s the necessary code to implement this:
class User {
String name
static hasMany = [groups: Group, groupSubscriptions: Group]
static mappedBy = [groups: "members",
groupSubscriptions: "subscribers"]
static mapping = {
groupSubscriptions joinTable: "user_group_s"
}
}
class Group {
String name
static hasMany = [members : User, subscribers: User]
static belongsTo = User
static mapping = {
//
table "group_"
subscribers joinTable: "user_group_s"
}
}
Grails will create two relationship tables user_group_ and user_group_s. Having the back reference from Group to User isn’t so bad, since the collection is lazy loaded. I would have just preferred not to pollute the domain class.
Conclusion
I hope that someone out there finds this information useful, I’d hate to see another Grails newb fall into this big dark pit that I call lack of documentation.
That said, my experience with Grails and Groovy so far has been pretty awesome. If you’re looking to develop a web-app rapidly, I’d definitely be looking at Grails as an option.