Remember, it’s simple to bind properties to a closure when those properties exist before the closure is created: Just define them. But how could you create a library of closures for user to consume?

def c = {
	println a // a isn't know here
}

def a = "Hello"

def binding = new Binding ()
binding.setVariable ("a", a)

c.setBinding (binding)
c.call()

As you can see, the property a isn’t known at the time the closure is defined. The binding allows to “inject” it later.

Groovy!

In word: Development with Eclipse has become Groovy, again.

Links:
Groovy-Eclipse 2.0.0M2 New and Noteworthy
Groovy-Eclipse 2.0.0M1 New and Noteworthy

class Knowledge {
    Set tags;
    Knowledge parent;
    List children;
    String name;
    String content;
}
class Tag { String name; }
class Relation { String name; Knowledge from, to;

A most simple model but it contains everything you can encounter in an application: Parent-child/tree structure, 1:N and N:M mappings. Now the idea is to have a way to build a UI and a DB mapping from this code. The idea of traits is to implement real properties in Java.

So instead of fields with primitive types, you have real objects to work with:

    assert "name" == Knowledge.name.getName()

These objects exist partially at the class and at the instance level. There is static information at the class level (the name of the property) and there is instance information (the current value). But it should be possible to add more information at both levels. So a DB mapper can add necessary translation information to the class level and a Hibernate mapper can build on top of that.

Oh, I hear you cry “annotations!” But annotations can suck, too. You can’t have smart defaults with annotations. For example, you can’t say “I want all fields called ‘timestamp’ to be mapped with an java.sql.Timestamp“. You have to add the annotation to each timestamp field. That violates DRY. It quickly gets really bad when you have to do this for several mappers: Database, Hibernate, JPA, the UI, Swing, SWT, GWT. Suddenly, each property would need 10+ annotations!

I think I’ve found a solution which should need relatively few lines of code with Groovy. I’ll let that stew for a couple of days in by subconscious and post another article when it’s well done

Wikis basically allow to publish mostly unstructured data. I say “mostly” because wikis give them some structure but not (too) much: You can organize it in pages and put it into context (by linking between the pages). Often, this is enough. But recently, MediaWiki has started to add support for structured data. See that infobox in the top left corner? But that’s just half-hearted.

XWiki takes this one step further. XWiki, as I understand it, is a framework of loosely coupled components which allow you to create a wiki. The default one is pretty good, too, so most of the time, you won’t even get into this. The cool part about XWiki is that you can define a class inside of it. Let me repeat: You can create a page (like a normal text page) that XWiki will treat as a class definition. So this class gets versioned, etc. You can then add attributes as you like.

After that, you can create instances of this class. The instances are again wiki pages. You can even use more than a single instance on a page, for example, you can have several tag instances and a single person instance. Instances are versioned, too. Of course they are, this is a wiki!

Now you need to display that data. You can use Velocity or Groovy for that. And guess what, the view is … a wiki page. So your designers can create a beautiful look for your the boring raw data. With versions and comments and everything. While some other guys are adding data to the system.

In “normal” wiki pages, you can reference these instances and render them using such a template. The same is true for editors. With a few lines of code, you can create overview pages: All instances of a class or all instances with or without a certain property or you can use Groovy to do whatever you can think of.

Now imagine this: You have an existing database where your marketing guys can, say, plan the next campaign. They can use all the wiki features to collect ideas, filter and verify them, to come up with a really good plan. Some of that data needs to go into a corporate database. In former wikis, you’d have to use an external application, switch back and forth, curse a lot when they get out of sync.

With XWiki, you can finally annotate data in your corporate database with a wiki page, with all the power of a wiki and you can even display the data set in the wiki and edit it there. Granted, the data set won’t be versioned unless your corporate database allows that but it’s simple to do the versioning in the data access layer (for example, you can save all modifications in a log database).

Suddenly, possibilities open up.

James Gosling gave a broad overview what is currently happening at Sun. Nice video but little meat. I asked about what happened to closures but I’m not sure whether I can repeat his answer here. My feeling is that, behind the scenes, there’s a lot of emotions and that’s bad. Oh well, maybe some will simply implement something reasonable in the OpenJDK. Otherwise, Closures are probably dead in Java which is a bit of a pity.

Dirk König showed a the most common use cases for Groovy in a Java project. Nothing really new for anyone who had been in contact with Groovy for nicely packaged and showed some cool stuff you can do with this mature language.

After that, Neal Ford explained how Design Patterns started to disappear. We didn’t really notice but things like Iterators or Adapters have become features of the language itself. In Java, you still have to query a container for an iterator, in Groovy, you just container.each { … do something with each item … }. Really nice talk, as usual.

Missed most of the next talk because I talked to Dirk König but if you’re using Maven or Ant as a build system, you should have a look at Gradle. It fixes most of the issues with Ant and some of the ones with Maven. Later that day, Hans Dockter (a Gradle developer) and I tossed a couple of ideas back and forth how the build could be improved. If any of these could be implemented, we’ll see a new way to build software.

At 15:00, Jason van Zyl told us what is happening in and around Maven. His talk was so full of information, it was impossible to follow the slides and him. Maven 3.0 is due early 2010 and it will solve a lot of the issues in M2. One of the most important features: You get hooks to run stuff before and after a lifecycle phase. Ever wanted to calculate a build number? Now you can.

M3 is based on SAT4J, just like Eclipse p2. Now, if you followed my blog, you know that I hate p2. p2 is a piece of banana software, delivered green, ripes at the customer. Which is a pity. p2 solved a lot of the issues with the old installer and it could solve all the other issues but apparently, there are forced behind the scenes which make this almost impossible. So when you meet Pascal Rapicault next time, don’t blame him for all the misery he has caused you. He has to solve a mission impossible and that only works in movies.

Later that evening, Thomas Mueller talked about Testing Zen. Nothing really new but I’ll probably have a look at H2 next week or so. It could replace my favorite in-memory Java database HSQLDB.

The closing session was by Neal Ford again. I wish I could create slides that were only a fraction as great as his. *sigh* Anyway, he drew a large arc from how technologies can become obsolete within a few years (as we all know), how good intentions pave the road to hell, about our responsibilities as software developers which go beyond what’s in our contract and predicting the future. Well, Terminator is probably not a good example but everyone knows it. Still, I find it troubling that the military is deploying thousands of automated drones for surveillance. You don’t? How would you feel about a robot equiped with a working machine gun that is programmed to automatically fire on any human that isn’t wearing an RFID tag? Samsung installed a couple of them along the northern border of South Korea two years ago. Skynet, here we come!

What they don’t teach you about software at school: Be Smart!, the last talk of the day, was disappointing. I’ll give Ivar that he had to compete against Neal but … The topic was okay and what he said was correct and all but the presentation could use some improvement. ‘Nuff said.

Here is an artical on Java World which gives some nice examples how to create a slang in Java and in Groovy. Pizza-lovers of the world, eat your heart out.

Here is the link to the presentation as OpenOffice document. Feel free to post any comments or questions below.

Remember that old OO promise to allow to mirror the world in a programming language, to allow to model the code after what the customer had in mind? Turns out, that OO was … nah, not lying … it was just overselling itself because customers don’t think in objects or models. They think jargon. And DSL’s allow you to make a compiler understand jargon. That’s even possible with Java even though “Java is like taking to a retard”: You always have to repeat yourself to make sure that the stupid compiler gets what you want (pun intended).

A DSL is not to be confused with an API. An API uses explicit context like “obj.setThis(…); obj.setThat(…);” etc. Here “obj” is the context and “setXyz()” is not meaningful without knowing the object we’re talking about here. A DSL, on the other hand, is all about context and context is implicit. It goes “obj.should(…).allow(…).this(…)”. An example is hamcrest: “assertThat(theBiscuit, is(myBiscuit));” Reads fluently, compact code, and it’s obvious that “is(myBiscuit)” should be compared to “theBiscuit” in some way.

The handouts of his presentation are available from his homepage but without his witty remarks. A pity but still worth to check out if you want to see just how far you can push Java to get code that your customer might understand.

In his talk, Ted crammed a pretty complete introduction in the key features of Groovy into three hours. For me, the key points of the talk were these: Productivity and ceremony.

Research shows that all developers roughly write the same amount of code lines per day. The difference between guru developers and the greenhorns is that the gurus write a line once and it works first try and each line achieves much more in respect to reaching the goal than any line of a novice. So in order to boost productivity of a guru, the only way is to use a programming language which can achieve more in a single line of code (and we’re talking one statement per line here, obviously). So it’s not that the guru writes ten times as much code per day as the novice, the novice just writes every line ten times because every time, (s)he gets something wrong and has to fix it.

The other aspect is ceremony. A lot of code in Java is ceremony. In most cases, the Java compiler knows where a statement ends and it wouldn’t need the semicolon. Still it insists that I press the key anyway (and it’s two keys on the German or Swiss keyboard). The same goes for many other things in Java which are just there for tradition. It would be simple for the Java compiler to infer the type of an object after if (obj instanceof ...). There really is no need for the cast in the next line. I could find another 10 examples easily.

Groovy does away with all that. It comes at a price, though. If you like to rely on the compiler creating a cozy padded cell for you, checking types and syntax as much as possible, then Groovy is not for you. In Groovy, the idea is that the developer knows exactly what (s)he’s doing and all (s)he needs is the fastest path to get there. You can do all the dirty things you wished for in Java but you don’t have to. Groovy is an “also” language, not an “either-or” language. If you feel that Java is dirty enough, already, try Scala.

Thanks, Ted.

If you want to know more about Groovy and you’re in Zurich, why not attend my talk on Thursday?

If you are, then you have a “complexity budget“. I define it a little bit differently than the author of the article. My definition is that you can spend only so much on understanding something. Example. What does this little C program do?

_(__,___,____){___/__1&&___%__<___/__?_(__,1+
___,____+!(___/__%(___%__))):___<__*__?_(__,___+1,____):0;}main(){_(100,0,0);}

It prints the primes below 100. And it blows the complexity budget. C++ also often blows the complexity budget. A friend of mine once said: “To understand C++, you have to be a C++ compiler.”

Java once was a simple language but the wise guys with a sun-burn (from being exposed too long to the sun, get it?) decided to do something about it and came up with Generics. And since they weren’t sure that this would indeed make the language too complex, they added annotations on top of that. Excellent move!

But it didn’t work. There are still too many people who use and understand Java. So they came up with JSR 308 which allows you to use annotations in even more places to write code like this (from this article):

@NotEmpty List strings
        = new ArrayList();

If that doesn’t do it, nothing will.

On a positive side note, in Groovy, I can not only register an annotation processor (AP) in the compiler, I can even manipulate the AST from the AP, allowing to create code like this:

@GroovySQL(type=DemoType.class)
def load(long id) {
    return """select * from demo_table where id = ${id}""";
}

That doesn’t return a string but an object of type DemoType filled with the data from the database. Life can be so simple.

And to the guys from Sun: Thanks a lot! We really appreciate your help!

Links: Article by Michael Nygard about JSR 308