The Cafes » Blogroll

I’ve probably wasted two hours over the last couple of days trying to debug this line of code:

private static final QName name = new QName("valid-isbn", "http://www.example.org/books");

Do you see the bug? I’ve made it even easier to find by showing you just the line that contains the bug; but it still doesn’t jump out at you. Originally, of course, I didn’t know this was the buggy line. The exception was thrown somewhere completely different in the code base, but this is indeed the buggy line.
(more…)

I’ve been trying to clean up the serialization story in Jaxen lately. Bottom line is that you really shouldn’t just willy-nilly declare that classes and interfaces implement Serializable. Getting serialization right is not hard, but it is tedious, and it needs to be thought about and tested. There’s a lot more to it than just adding implements Serializable to every class.

After I filed one bug, the usually reliable Brian Ewins made the comment that, “I also thought it was considered best practice not to declare interfaces serializable.” That sounds plausible, but I can’t really figure out why, nor can I make strong case for the opposite position. So here’s the question. Given an interface Foo is it or is it not a good idea to declare that Foo implements Serializable? (given that you do in fact want the instances to be serializable, of course.) Or should one leave implements Serializable off the interface and just place it on the concrete classes? Why or why not?
(more…)

Most object oriented programming textbooks and courses explain the need for access protection and data encapsulation by claiming that it separates interface from implementation. Thus it allows programmers to vary the implementation independently of the interface for optimization, backend changes, or other reasons. This is wrong, and this claim is the source of a lot of bad theorizing on a host of subjects including finality and the choice between interfaces and concrete classes.
(more…)

All the hoohaw over finality, its goodness or badness, and whether or not it should be the default, suggests it’s worth exploring the background. Why do I feel so strongly that final should be the default (at least for methods) and what changes could be made to modify this belief?
(more…)

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.
(more…)