log4p

Recently the Google Collections Library came to my attention. The Google Collections Library is a suite of new collections and collection-related goodness for Java 5.0, brought to you by Google.

Since I’m a frequent user of apaches’ commons-collections library I wondered what the difference is.

From browsing the API and FAQ it seems that:

• It fully based around Java5 features, which is a big issue of commons-collections
• Implementations adhere to the contracts specified by the JDK interfaces
• Almost all implementations are final, according to the FAQ extension should be done through decoration using the ‘forwarding collections’
• They haven’t done any my favorite ‘LazyXYZ’ implementions yet

From the looks of it I think we will see this nice library being adopted quite fast; I’ll certainly be using it on future Java projects. Maybe I’ll even write some ‘LazyXYZ’ decorators using the ‘forwarding collections’!

Writing tests for a Grails applications is really simple. In Groovy code actually compiles when non-existing methods of objects are referenced (as opposed to Java) which makes it possible exercise TDD (test driven development).

Grails supports two types of tests out of the box, unittests and integrationtests. Tests are located in the test folder of a generated Grails project.

Lets start with a simple integration test (I'll feature webtests and the like in a follow-up to this post) for a domain object.

First, create a domain class using the "grails create-domain-class" command. This will create a domain class AND the skeleton to write integration tests for the generated class (I choose to use the Battle class of the presentation I gave yesterday). The skeleton will look something like this:

Now, we want to test and see if we can store the expected fields in the battle object:

Running the test (grails test-app Battle) results, as expected in a failure:

After running the tests Grails creates a nice HTML overview of all the results as well:

In the image above you'll see the error message "No such property: name for class: Battle
". Adding the property to the Battle class fixes this and results in a successful test:

Apart from the default assertion methods inherited from the JUnit framework's TestCase class, GroovyTestCase also offers a couple of other assertions handing us quite a useful/complete set of tools.

Yesterday I presented at the Battle of the Geeks 2007 organized by my employer. 4 presentations where given and people in the audience where asked to rate each presentation using special cards. (I translated this post to Dutch for the Finalist developer blog)

19.15 Presentation 1: CMS Container

Freek Punt talked about Finalists' own MMBase based open source product: the CMS container. Good presentation, overall I was quite impressed by what they've managed to do in the past year. 15 minutes of screencast did however seem a bit to much to me. 3 (out of 5) stars

19.45 Presentation 2: Guice

Che Schneider did a very nice presentation on how Googles' Guice allows a developer to drink more beer AND spend more time with his/her family. Very good presentation: I voted 5 stars: kudos to Che!

20.30 Presentation 3: Grails

My presentation on Grails. To start of I used the following presentation:

pdf
I'll add some screenshots and code to the presentation for the not-so-source-code-savy amongst us later on
One of my main objectives was to actually do some live coding. I succeeded on that, but was a bit short in time and had to skip almost half the stuff I planned to do. I did however build a working application from scratch. Code available here.

21.00 Presentation 4: Mule

Jianci Li didn't get off at a quick pace. Most developers just haven't put their mind around SOA/ESB infrastructures and this presenation sadly didn't help. Two stars. Things I missed during this presentation: what problem is actually solved by Mule (yes, I do know the answer... it should however been in the presentation)

So at the end, Google-Guice-Che won the battle, he got the hat! But winning isn't everything: I had a great time!

While setting up JAXB2 for converting object graphs to XML I came across a not-so-nice part of the annotations specification. While looking for a way to define a package level annotation (never needed to do this before) I found the solution a bit surprising:

To define a package-level annotation one has to create a file called 'package-info.java' in the root of the package and put the annotations on the package:

'package-info.java'?? Grrr... since it doesn't contain a type definition it doesn't even pop-up in Eclipses' source browser!

But hey... need to put them somewhere!

When the compiler encounters package-info.java file, it will create a synthetic interface, package-name.package-info. The interface is called synthetic because it is introduced by the compiler and does not have a corresponding construct in the source code. This synthetic interface makes it possible to access package-level annotations at runtime. The javadoc utility will use the package-info.java file if it is present, instead of package.html, to generate documentation.... I guess I should have known that I do however still prefer the package.html convention.

Groovy 1.1. beta 3 was announced a couple of days ago and includes some interesting additions to the groovy language, like a real method missing. Grails' lead developer Graeme Rocher has a simple example of the way it works in his blog:

Much better (IMHO) then previous way to do this, which involved intercepting ALL calls to the object on which one would like to catch method missing calls.

Recently a really interesting wicket extension emerged: Wicket Web Beans (WWB).

Wicket Web Beans (WWB) is an Apache Wicket component toolkit for displaying and editing POJOs that conform to the JavaBeans specification. Web pages are automatically generated based on bean properties and certain conventions. If necessary, the layout, editability, and actions of these pages can be customized on an exception basis. In other words, the toolkit normally does what you'd expect, but when it doesn't, you can override its behavior.

I clicked through the introduction to see how WWB works.

To edit properties of a POJO you actually don't have to do anything; a simple form is generated. If setters are not present for a property no input field is generated.

To customize the layout WWB introduces a properties flle with a simple DSL to go with the bean (same name, ends with beanprops). The syntax is simple (and a bit similar to YAML):

This file tells WWB : whenever you see a TestBean bean, lay it out in a one-column grid ("cols: 1") and display the properties ("props") in the order specified. Note that you refer to JavaBean properties without the prefix of "get", "set", or "is" and the first character is lower case. Also in the "props" parameter, we say "-number". This tells WWB to remove the "number" property from the page.

Personally I think this is a bit clumsy: the layout configuration is about the same amount of code needed to actually write your entire model in Grails.

But this isn't where it stops. WWB is quite extensive, one can add all sorts of components/widgets like calendars, tables etc. to the form definition.

Potentially WWB could be very powerful, but I really think that the introduction of a separate file/DSL won't increase the transparency of the application. I'll be sticking to Grails for now!

I was asked to do a series of presentations and workshops regarding Spring MVC at the HvA. Last Friday I started off with a presentation and some live coding examples.

Although the students didn't have much experience with Spring or Java web development I think I did manage to give them some ideas about what Spring MVC is.

PDF

The presentation was made (and presented) using Omnigraffle. If you would like to use some material for your own presentation: no problem, but please let me know.

Source code used and written during the presentation can be found here.