Specification by Colonization

The final chapter of the recently published Java I/O, 2nd edition focuses on the Java Bluetooth API. Like about half of what’s going on in Java today the Java Bluetooth API was defined and developed in the Java Community Process (JCP). I spend a lot of energy criticizing the W3C process, but compared to the JCP, it’s a model of sanity.

At first glance JCP specs look OK; but once you really start digging into one at the level you need to write a book about one or implement it, you rapidly discover huge areas of unspecified behavior. Then when I write about it, I have to test the implementations to see what they actually do. I rarely test more than one or two, and then I write down its behavior as what happens. Then other people come along and read my book to figure out what they’re supposed to. The behavior that gets fixed is chosen almost by accident.

I blame this on the JCP‘s culture of implementation as specification. Many specs are nothing but the JavaDoc compiled from the reference implementation and pointlessly encoded in PDF and/or a zip file. The specs are thus only marginally better than documentation for a typical software product (i.e. slightly better than wretched).

By contrast W3C specs are normally written independently of implementations. Then the working group checks to see if the specs can actually be implemented in a compatible fashion. Since they require two implementations of each feature, this tends to identify any grey areas in the spec, especially when the people doing the implementing are not the people who wrote the spec.

This entry was posted on Monday, May 29th, 2006 at 7:13 am and is filed under Blogroll, Open Source, Testing. You can follow any responses to this entry through the Atom feed. Both comments and pings are currently closed.