This is the second installment in my summary of the sessions I attended at JavaOne this year.

The previous installment covered Java futures. This one covers Java programming practice.

Once again, the titles here are not always the ones that appear in the conference programme. I tried to undo the mangling that the Trademark Police typically impose on talk titles, so let me just state up front that Java, JMX, and JVM are trademarks of Sun Microsystems, Inc., and any other abbreviation beginning with J has a sporting chance of being one too.

Here are the talks summarized in this installment:

More "Effective Java"
Defective Java
Using FindBugs in Anger

In the remaining installments, I'll cover Concurrency, JMX, and Miscellaneous others.

TS-6623, More "Effective Java", Joshua Bloch. This talk was excellent but I didn't learn all that much from it that I didn't already know. The one new thing that I took away is that if you want to implement the smelly singleton pattern in Java, the best way is now to declare an enum with just one constant.

Pedant moment. Josh claimed that there is no term for a group of eleven musicians (like septet for seven or dectet for ten), which I took as a challenge. The logical term, given that the Latin for eleven is undecim, should be undectet, and indeed Google finds a fair number of hits for that. It's true that most of them do seem to be from the same source, but not all. In the book Josh says there is no standard term, and I think it would be hard to argue with that.

Speaking of the book, copies of it fresh off the press were selling like hot-cakes at the conference. I came home with one, after nearly losing it on the plane, and it is of course first class.

TS-6589, Defective Java, Bill Pugh. Subtitled "Turning WTF code into a learning experience". Of course the Trademark Police made it into "Defective Java™ Code", but they would, wouldn't they.

This talk covered a number of bug patterns that the indispensable FindBugs tool knows about. Bill and his coconspirators have been very good about building a catalogue of these patterns from all sorts of sources. He's made a habit of grabbing mistakes wherever he sees them, including ones he makes in his own code that he immediately notices just after typing them! I'm reminded of Knuth's massive TeX bug log, except that here the errors are captured in a machine-understandable form, to prevent other people from making similar ones.

I was mortified to see that one of the bug examples was from the JMX implementation in the JDK, in some code that hasn't been touched since 2000. The bug pattern is synchronizing on the value of a field to protect an assignment to that field...

synchronized (sequenceNumber) {
    sequenceNumber = new Long(sequenceNumber + 1);
}
  

I'd actually stamped out a bunch of other occurrences of this sort of thing, but missed this one. It's actually completely harmless, but embarrassing. Well, I didn't lose any time logging a bug report and fixing it in JDK7, along with lots of other potential problems reported by FindBugs.

TS-6590, Using FindBugs in Anger, Bill Pugh. In this follow-on talk, Bill talked about some practices that are useful when using a tool like FindBugs on big code bases (>100,000 lines). There's a law of diminishing returns, and you need to decide how much effort to invest in this approach. Bill suggested concentrating on high and medium priority warnings, and on certain categories (notably "correctness"), which depend on your code base. He discussed practices to avoid having to wade through the same error reports every time you make a change. There was more in this very dense talk than I want to summarize here, so I'd encourage those interested to check out the slides.

In the next installment I'll cover the sessions on concurrency.

[Tags: javaone javaone2008 findbugs undectet java effective+java.]