The Cafes » Blogroll

Here’s an interesting article that is totally, completely 180 degrees wrong. I’ve said this before, and I’ve said it again, but I’ll say it one more time: final should be the default. Java’s mistake was not that it allowed classes to be final. It was making final a keyword you had to explicitly request rather than making finality the default and adding a subclassable keyword to change the default for those few classes that genuinely need to be nonfinal. The lack of finality has created a huge, brittle, dangerously breakable infrastructure in the world of Java class libraries.

(more…)

There’s one trap I fall into repeatedly while doing software development of any kind: testing, debugging, coding, documenting, anything. And it happens in every language I’ve ever worked in: Java, C++, Perl, CSS, HTML, XML, etc. The only difference is how much time I waste tracking down the bug.

I have this on my mind now because I just lost at least half an hour to this while working on the CSS stylesheet for this very web site. I have had many students show up during my office hours for help with debugging this problem. I have had at least one company pay me lots of money to fix this problem for them (though they didn’t know this was their bug or they wouldn’t have needed to call me in the first place). I can virtually guarantee you’ve made this mistake too. What is the mistake?

Editing the Wrong File
(more…)

Optimization is a subject fraught with witchcraft, voodoo, and superstition. Far too often it is done badly and pseudoscientifically. The first rule of optimization is that you can’t do it without measuring . Almost any guess you make about performance is at best irrelevant and often actively harmful. A common technique is to write a benchmark that runs the piece of code you’re trying to optimize several thousand times, and prints out the time it takes to run. Then tune until the time comes down.

They’re at least ten reasons why this technique fails more often than it succeeds (forgetting to account for HotSpot initialization, optimizing a piece of code in which the program spends a trivial amount of time, etc.) but recently I encountered an 11th: the benchmark may not be exercising the code you think it is. This turns out to be surprisingly common, and the more complex the code is, the more likely this is to occur.
(more…)

At some point, a new java.io.IOError class was added to Java 6. This is “Thrown when a serious I/O error has occurred.” No further explanation is offered.

This is not listed as a change in the JDK 6 documentation; and I haven’t noticed this addition in any JSRs, though I could easily have missed one. Can anyone explain where this new class has come from and what is likely to cause it be thrown?
(more…)

One advantage of test-driven development I’ve rarely seen emphasized is that it enables experimental programming. This was recently brought home to me while I was working on XOM. Steve Loughran had requested the ability to use a NodeFactory when converting from a DOM document. It was a reasonable request so I set off to implement it.

My first iteration satisfied Steve’s use-case. It was actually a fairly major rework of the code, but the test suite assured me that it all worked and I hadn’t broken anything that used to work. However, Wolfgang Hoschek quickly found a real bug in the new functionality I had added; and things got a little sticky here.

To satisfy John Cowan, the DOMConverter uses some fancy non-recursive algorithms. This enables it to process arbitrarily deep documents without stack overflows. However the algorithm is far from obvious; and even though the code is well-written it’s hard to come back to it a couple of years later and figure out just how it works.

But this is where test-driven development really shines: I don’t have to understand the code to fix it. (more…)