Skip to main content

JavaOne report: Java programming practice

Posted by emcmanus on May 26, 2008 at 8:06 AM PDT

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: rel="tag">javaone rel="tag">javaone2008 rel="tag">findbugs rel="tag">undectet rel="tag">java rel="tag">effective+java.]

Related Topics >>

Comments

"Undectet"? Cool! You learn something new every day.

Josh

Wow, close reading! In fact the changeset I linked to above was incomplete because of a slip-up, and I had to make a second small one to correct the missing parts, including the case you noticed.

About the JMX implementation in the JDK: @@ -458,8 +455,7 @@ public class Timer extends NotificationB // Create and add the timer notification into the timer table. // - Integer notifID = null; - notifID = new Integer(++counterID); + Integer notifID = new Integer(++counterID); So why not Integer notifID = Integer.valueOf(++counterID); All other occurrences of Wrapper constructors were exemplary substituted through valueOf().