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 : Personal Practices Map

In the evening, everyone had a chance to run a Birds of a Feather session. I thought I’d give it a go and repeat the session from XtC last year.

It was a chance to talk to other developers about the little things we do that help guide development.

It was a calm and enlightening session. I felt I learned a lot from the attendees. Techniques that I would probably otherwise never know about unless I actually paired with them.

I look forward to doing this again at ADC.

Romilly generated a topic map from the results: (click here)

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 – http://proxytoys.codehaus.org/

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.

OT 2004

So here I am, about to start the final day of OT2004. I overslept this morning and missed my chance to join the main conference room for todays keynote. Joshua Bloch is in there now talking about how to design a good API and why it matters. I’d like to have heard that. Instead I’m taking advantage of the wireless network to blog.

It’s been an awesome conference. Besides going to many great sessions, I’ve had the chance to hang out with awesome people, talk tech and play with code.