Posts Tagged ‘ Java ’

OT2004 : Taming the Tiger (Java 1.5)

This session was presented by Benedict Heal, and he was brilliant; concise, clear, humourous and extremely chilled out. Even the fact that Josh Bloch was listening in on his presentation didn’t phase him.

Most of the new Java 1.5 features are already widely known. Generics, annotations, auto-boxing, enums, syntactic sugar, yada yada yada.

Some things that caught my eye:

* -Xlint : a compiler flag to warn you when your code can be improved to take advantage of new features such as generics.
* Generics are not available at runtime (unlike C#).
* Use of generics all over the API, not just collections. For example, Class is a genericised type, so newInstance() returns the correct type.
* List<MyThing> cannot be given a List<ExtendedMyThing>. Makes sense really as otherwise you’d be able to add things that it shouldn’t allow.
* Genericised types can be constrained to only allow certain type. class Blah<T extends MyThing>.
* Wildcards allow even more flexibility: List<? extends MyThing> list = new ArrayList<ExtendedThing>() // valid.
* Or this: List<? super ExtendedThing> list = new ArrayList<MyThing>(); // valid
* Generics are complicated :)
* Annotations can be specified as source level, class level (available for inspection by class loader) or runtime level (available through reflection).
* Variable parameters to a method. Defined like this: printf(String format, Object… args). The three dots are part of the syntax! Called like this: out.printf(“Blah % blah % blah”, 44, “hello”, someObject). Note autoboxing comes into play too.

It’s only a shame there isn’t a feature such as the anonymous delegate in C#… now that is real power. Rock on Java 1.8.

OT2004 : Elegant Implementation of Null Objects

Since Dan and I have both been working together again (2 years at ThoughtWorks) and since I moved into a house less than ten minutes walk from his, we very rarely see each other. So it was good fun to have a geeky catch up session and play with some code.

Something Dan showed me:

interface Something {
Something NULL = (Something)Null.object(Something.class);
// more stuff…

The Null class is a simple dynamic proxy that will return an immutable null object that does nothing. Methods that return values will return default primitives (0, false), empty arrays or more dynamic proxies.

So at any point in the code you can call Something.NULL to get the null implementation.

Nice! (Dan, upload it somewhere!)
Update: He did –

OT2004 : Towards EJB 3.0

Despite the title, this session, led by Scott Crawford from the EJB expert group, turned out to be one of my favourites.

I’m a bit rusty on EJB. I was big into EJB for a few years and then one day I just stopped using it. I spent some time before the session reminding myself of the way of the EJB. Actually, EJB ain’t that bad.

This session was an opportunity to have our say about problems we see with EJB. Something we were clear on doing was focussing on the problems and consequences rather than “wouldn’t it be nice if…” solutions. Between us we came up with our top thirty gripes. In fact there were many more we could have come up with but didn’t have time.

From there we went through each of them and voted on whether we recognised the problem and, if so, whether it was deemed important. This narrowed it down to ten. Each of us then represented an issue close to our hearts and defended it in a debate with the goal to narrow it down to three.

The problem I represented was that EJBs only expose one coarse grained business interface to the outside world (ignoring the home/local/remote thing). This coarse grained API based exposes methods to clients (including other EJBs) that are not necessarily relevant. Objects (and EJBs) are different things to different people and by depending on the interface for the entire implementation, rather than a specific fine grained role, you end up with a higher coupling of components in the system and reduced flexibility. Most other APIs get this right but EJB prevents you.

Needless to say, I never made it into the top three. I had no chance against:

* Testability.
* Transparent persistence for entity beans.
* Death to RemoteException.

And to be fair, they are much more important :).

Some of the other things that made it into the top list (off the top of my head):

* More flexible O/R mapping, relations and finders.
* Breaking the 70’s paradigm shift of separating state and behaviour into entity and session beans. Whatever happened to OO?
* Simpler deployment.
* Declarative error handling.
* Lazy loading / pageable iterators in the specification.

Anyway, the results of this are to be fed back to the EJB group and I really hope they can make a difference. Time will tell.

Kudos to Scott for hosting a good session. Everyone came out feeling good about themselves. And well done to Robin Roos for being on best behaviour and not mentioning JDO once :). It was also reassuring to see the developers from BEA violently agreeing with all of our gripes – they too are victims!

OT2004 : Generic Mechanisms in Software Engingeering

This workshop, hosted by Simon Davies, and chums from Microsoft (with a bit of Bruce Anderson), was a thinking excercise about the pros and cons of some of the language features of C# (and conveniently also Java) including generic types, attributes and dynamic code generation.

We were given some sample scenarios to which we had to contrast the approaches of using these features in isolation and combined together, taking into account ease of development, runtime performance, flexibility, maintainability and simplicity:
* Creating a strongly typed list.
* Serializing objects to XML (a subject I’m familiar with).
* CRUD persistence of domain objects to a database.

This was quite thought provoking. While it was very easy to see the advantages of using generics to implement a strongly typed list, experimenting with all the different approaches was a fun exercise. Code generation may be less simple but offers better runtime performance.

It was fun brainstorming ideas with developers from different backgrounds and seeing which approaches appealed to them.

I was also shown the anonymous delegate feature in the next version of C#. Mmmm closures…

// usage
int totalAge = 0;
peopleFinder.All(delegate(Person person) {
totalAge += person.Age;

// implementation
class PersonFinder {

public delegate PersonDelegate(Person person);

public void All(PersonDelegate delegate) {
some magic iteration code {
Person person = ...;


Now for a staticly typed language, that’s a lot cleaner than I was expecting.

This is something I’m really excited about as it’s the style of development I use all the time in Java, without all the syntactic cruft of anonymous inner classes. And I’m sure it’ll appeal to all the Ruby/Smalltalkers out there.

Something else I learned is that (unlike Java 1.5), generic definitions are available at runtime.

Plenty more info in the C# 2.0 specification.

OT2004 : Mock Objects: Driving Top-Down Development

Nat and I were first up with our talk on Mock Objects. Yes, we are still harping on about them :).

Here’s what we covered:

* OO concepts: an application is a web of collaborating objects, each providing a distinct responsibility and taking on multiple roles to provide services to other objects.
* How the process of using mock objects complements TDD to drive out the design of these responsibilities and roles.
* How our original usage of mocks for testing system boundaries such as databases, web-apps, GUIs, external libraries turned out to be a bad approach and the success we started achieving when inverting this to only mock types we can change.
* The process of using mocks very quickly points out key abstractions in your system, difference in responsibilities between objects and services objects require.
* Clearing up misconceptions about mocks, including: not using them at system boundaries and what they actually are (not stubs, not recorders, no behaviour).
* Our first public demonstration of the new JMock API to walk through a single iteration of the process.
* Usage patterns.

Feedback from: James Robertson @ Cincom Smalltalk and Mike Platt @ Microsoft.

Making JUnit friendlier to AgileDox

Here’s a little trick to make JUnit display your test results in a similar way to AgileDox.

Override TestCase.getName() in your unit test…

public String getName() {
return super.getName().substring(4).replaceAll("([A-Z])", " $1").toLowerCase();

… and your test runner results are transformed from this …

… to this …

To make this easier, stick it in an abstract TestCase and inherit from that instead.

What’s a YAUL? Or a YAUC?

Hani has a very valid post about util libraries.

Libraries that just have a bunch of non focussed utils in them, rarely provide a benefit to anyone other than the original authors.

When developers are looking into using a third party library, it is for a specific reason. A library that has a specific focus may meet this requirement, whereas an all-purpose util library rarely will (and even if it does, it is unlikely that it will be found).

Much of the code within the library may serve little purpose outside the context of the application it was originally built for, but not necessarily all.

By identifying the code within that has defined focus, you can extract that out and provide a library with a specific purpose.


Whilst developing many parts of OpenSymphony (and our own bespoke applications that use OpenSymphony), we noticed there were many odd little methods that we found useful, which lead to the conclusion that other people would also find them useful. We slapped them together into a util library and OSCore was born.

This library lacked a clear responsiblity and in the end became a dumping ground for code that didn’t seem to belong elsewhere. As a consequence, it wasn’t successful. No one is going to choose to use a library that does this, that, a bit of this and has that really useful method there.

Eventually this was learned and the one part of the library that had a clearly defined use (PropertySet) was split out into its own project. Today, PropertySet is a well used library, whereas the rest of OSCore has faded into the background.

Incidently, this is a lesson we learned early on in OpenSymphony and the result has been many quality components since, many of which I rely on today.


As well as libraries, this also applies to individual classes. A class named CheeseUtil express very little about the focus of the class other than it’s got something to do with cheese. As a result util classes often grow fairly big and lack clear design (in fact, they often end up as a bunch of public static methods).

In this case a util class can be refactored into many smaller classes which can each flourish on their own, with their own design.

YAUC Example

In OSCore there’s a class called XMLUtils.

From the JavaDoc:

XMLUtils is a bunch of quick access utility methods to common XML operations.

These include:

* Parsing XML stream into org.w3c.dom.Document.
* Creating blank Documents.
* Serializing (pretty-printing) Document back to XML stream.
* Extracting nodes using X-Path expressions.
* Cloning nodes.
* Performing XSL transformations.

Authors: Joe Walnes, Hani Suleiman :)

Unless someone had specifically looked at the JavaDoc or methods of every single class in the system, there would be little chance of knowing that.

Breaking this class up into many smaller classes, errm, objects such as XMLParserFacade, XMLPrettyPrinter, NodeCloner, XPathEvaluator and XSLTransformere, expresses the intent clearer and is much more likely to be found.

(Hani and I have since learned from these mistakes).

h4. Conclusion

Small and clearly defined responsibilities for libraries and individual classes results in improved reuse as they have an increased chance of meeting part of a developer’s requirement.

When simplicity backfires

I put a lot of effort into refactoring a larger, more complicated library into the lean and simple Squiggle you see today.


bq. Freshmeat tries to avoid listing projects which fall below a certain level of size and/or complexity, and yours is unfortunately a bit too simple for our application index. Your contribution has been respectfully declined.

Easily build complicated SELECT statements with Squiggle

After serving me loyally for four years, I’ve finally got around to open-sourcing Squiggle – a small Java library for dynamically building complicated SQL SELECT statements.

Sometimes (not often these days) you just need to get your hands dirty and write a beastly SELECT statement. Maybe a persistence layer is deemed overkill for your application, or maybe a persistence layer is struggling with the type of query you want to do. There are times when writing some SQL is the right thing to do.

Here’s the blurb from the website:

Squiggle does one thing and only one thing. It generates SELECT statements based on criteria you give it. It’s sweet spot is for applications that need to build up complicated queries with criteria that changes at runtime. Ordinarily it can be quite painful to figure out how to build this string. Squiggle takes much of this pain away.

The code for Squiggle is intentionally clean and simple. Rather than provide support for every thing you could ever do with SQL, it provides support for the most common situations and allows you to easily modify the source to suit your needs.


* Concise and intuitive API.
* Simple code, so easy to customize.
* No dependencies on classes outside of JDK1.2.
* Small, lightweight, fast.
* Generates clean SQL designed that is very human readable.
* Supports joins and sub-selects.

Here’s a very simple example:

Table people = new Table("people");

SelectQuery select = new SelectQuery(people);

select.addColumn(people, "firstname");
select.addColumn(people, "lastname");

select.addOrder(people, "age", Order.DECENDING);


Which produces:

people.firstname ,
people.age DESC

Go check out the website and two minute tutorial.

Running Groovy natively without the JVM

Two days ago I was hacking away at some Ruby scripts and thought it would be nice if I could write them in Groovy (not necessarily useful, just nice).

Of course, for small scripts that honour the UNIX philosophy, that would be a terrible idea. These scripts should start instantly and have minimal overheads.

What changes would be needed to allow Groovy to compete with languages like Perl, Python, TCL, Ruby or plain old shell scripts in this space?

* Better performance / reduced overheads (cpu, memory, start-up time).
* Simple install (src tarball, RPM, dpkg, windows installer, OS-X whatever).
* No JVM required.
* Ability to use Groovy to access less Javaish libraries (POSIXy style stuff, MFC, .NET).
* Ability to use Groovy (and Java) objects from other languages (C, C++, Perl, Python, Ruby, .NET, etc)

As an experiment, I’ve created a subproject of Groovy (groovy-native) that aims to address these issues.

Take a peek at where I’m going with this.

So far:

* Created a stripped down native runtime library (
* Compiled a .groovy file to a native executable (linked with libgroovy).
* Created a native C++ app that calls interops with Groovy objects.