|By Janice J. Heiss, March 2006|
Java Puzzlers, a new book by Joshua Bloch, Google's chief Java architect, and Neal Gafter, Google software engineer and Java technology evangelist, contains some 95 "puzzlers" and is designed to amuse, tantalize, challenge, and educate Java developers. Bloch and Gafter model puzzlers on optical illusions: In each puzzler, initial appearances are deceiving, and things are not what they seem. As such, puzzlers tease developers into confronting some of the spontaneous assumptions that their minds generate when they read Java platform code - - an experience that Bloch believes can lead to more flexible and astute programming. Journals such as ACM Computing Reviews, Software Development Magazine, Slashdot, and JavaRanch have lauded the book, as have such respected authors of books on Java technology as Guy Steele, Gilad Bracha, Jeff Langr, and Ian Darwin.
Bloch, a former Distinguished Engineer at Sun Microsystems, won the prestigious Jolt Award from Software Development Magazine for his book Effective Java Programming Language Guide. At Sun, he led the design and implementation of numerous Java platform features, including JDK 5.0 language enhancements and the award-winning Java Collections Framework. He holds a Ph.D. in computer science from Carnegie-Mellon University.
We met with him recently to get a better grasp of the pleasures and benefits of Java code puzzlers.
You call the book Java Puzzlers. Is it all fun and games?
Nope. Neal and I hope that readers find the book entertaining, but it's designed to educate as it entertains. There's a lot of useful information in this book that isn't available elsewhere.
"Working through puzzles can 'inoculate' you against the traps and pitfalls of the Java platform."
Chief Java Architect at Google
How does working on Java programming puzzlers help developers discover their hidden assumptions?
Most of the puzzles confront the reader with a simple program, and the reader has to figure out what it does. It's usually pretty obvious what the program does but for one minor detail: None of the programs actually do what you expect them to. If you can't figure out what might be wrong with a program, you run it and find out what it actually does. (All the programs can be downloaded from the book's web site.) "Oh my gosh," you say, "Why did it do that?" Then you stare at the code for a while and try to figure out why it did what it did. If you're lucky -- or very smart -- you have an "Aha!" moment and figure out which innocent-looking bit of code is responsible for the program's misbehavior. Either way, you turn the page, and we explain the whole thing to you. Hopefully, the lesson sinks in, and you never make that incorrect assumption again. In this way, working through puzzles can "inoculate" you against the traps and pitfalls of the Java platform.
Why is the book illustrated with optical illusions?
One day, Neal and I were on the phone with our editor, Greg Doench, trying to figure out what to put on the cover of the book, and Neal had one of those "Aha!" moments that I mentioned earlier. He said, "Do you realize that these puzzles are optical illusions?" What he meant was that the programs in the puzzles appear to do one thing, and the longer you stare at them, the more they appear to do it. But when you run them, they do something entirely different. This is exactly how optical illusions work. They appear to have some property, and the longer you stare at them, the more they appear to have that property. But if you try to confirm it with a ruler -- or mask, for some illusions -- you find that they don't have that property at all. For example, these letters appear to tilt, with alternating letters tilting in opposite directions:
But if you color the letters yellow, you can see that they aren't tilted at all. The "candy stripes" inside the letters fool you into thinking the letters are tilted:
How does recognizing that initial appearances can be deceiving help people to become better developers?
Vision scientists study optical illusions to gain deep insights into the human visual system. In the same way, studying code illusions yields deep insights into the Java platform. But there is one key difference: Even if you understand why an optical illusion works, it doesn't stop working. If you understand how a code illusion works, you can stop making that mistake, and you can spot it in code that you're reviewing.
Has working on the puzzlers helped some developers to confront other programming problems?
Absolutely. For starters, when I was still working on the book, I showed Doug Lea Puzzle 3 ("Long Division," also available as Puzzle 1 in the sample chapter [PDF]). It caused him to go back to a library that he was working on and change the way a constant was defined. The other day, I stumbled on a web page where the GCJ folks found a bug in their compiler using one of our puzzles (Puzzle 45, "Exhausting Workout"). And just yesterday, a coworker came to me with a bug that turned out to be the same one in "Reflection Infection" (Puzzle 78).
You've focused a lot on what you call the "traps, pitfalls, and corner cases" of the Java platform. What did you learn?
The key insight is that nothing is perfect: Even the best programming languages have traps waiting to snare the hapless programmer. But that doesn't mean the situation is hopeless. We came to realize that there are a few key principles underlying many traps and pitfalls. If you learn these principles and act accordingly, you can avoid whole classes of problems. For example, the puzzles in Chapter 8 ("Classier Puzzles") all involve name reuse: hiding, overloading, shadowing, and obscuring. If you keep name reuse to a minimum, you avoid many problems.
One thing that surprised us was just how many traps and pitfalls are amenable to static analysis. If you run the puzzles in our book through Bill Pugh and David Hovemeyer's excellent FindBugs tool, it will spot many of the problems. But don't do that! It would be cheating, and it would take all of the fun out of the book. Instead, run your own programs through FindBugs. You'll be surprised at what it finds. It found several bugs in my programs -- including the JDK itself.
"Almost all of the puzzlers arose from real programmers struggling with real problems."
Chief Java Architect at Google
Do most Java technology developers make the mistakes you identify in the puzzlers? Did you have to make these mistakes yourself first before you could identify them?
It's a near certainty that every Java developer will get caught by some of these problems at one time or another. Neal and I have definitely fallen into some of these traps. Now that I'm attuned to them, I see them all the time in code that I review, even in code examples slated for publication.
Although a few of the puzzles may seem contrived, almost all of the puzzlers arose from real programmers struggling with real problems. As Neal pointed out, the richest source of puzzler material was JDK bug reports that were closed as "not a bug." If correct behavior misled programmers into thinking that they had discovered a bug, it probably represents a trap or pitfall.
I noticed in the errata that the book contains one real error. Would you care to comment on it?
Ah, yes... It turns out that even we are not immune from falling into these traps. In the solution to Puzzle 65 ("A Strange Saga of a Suspicious Sort"), we suggest a replacement for a faulty method in the puzzle. Unfortunately, our suggested replacement is also broken. We fell right into the trap described in Puzzle 32 ("Curse of Looper"). A colleague of ours, Yoshiki Shibata, discovered this while translating the book into Japanese. Unfortunately, the book had already been printed by the time Yoshiki discovered the problem, but we'll correct it in the second printing. If you're curious about the details, you can take a look at the errata page, but don't look until you've done Puzzles 65 and 32.
In one sense it's embarrassing, but in another, it validates the whole project. The traps and pitfalls described in Java Puzzlers are real, and no one is immune from them. If you want your programs to be bug-free, it's definitely in your interest to understand these traps and pitfalls.
Is there a particular set of assumptions or style of thinking that your puzzlers confront or unearth more than any other?
That's a tough one. I guess the style of thinking that most often gets developers into trouble is unwarranted optimism. There's a natural tendency to expect your program to just do the right thing, but the machine can't read your mind. Most of the facilities provided by the system have certain limitations that you have to be aware of. For example, an
int isn't the same thing as an integer: There are infinitely many integers, but only 2 32
int values. That means you have to worry about overflow. For example, you might think that this loop iterates over each
int value exactly once:
for (int i = Integer.MIN_VALUE; i <= Integer.MAX_VALUE; i++) doSomething(i);
It doesn't. It's an infinite loop, because every
int value is less than or equal to
Integer.MAX_VALUE. Once the loop gets to
Integer.MAX_VALUE, it wraps around to
Integer.MIN_VALUE and starts over again. That's just one simple example of this style of thinking, but it can be applied to every aspect of the language and its libraries with equally unpleasant results.
Are certain kinds of developers more likely than others to profit from your book? Is it oriented more toward developers of a particular level or a particular kind?
Any experienced Java developer could benefit from it. It isn't for raw beginners. If you're just learning the language, it will only confuse you. But if you read and understood Effective Java, then you're certainly ready for Java Puzzlers.
" Effective Java tells you what to do, and Java Puzzlers tells you what not to do. Once you know what to do and what not to do, you're all set."
Chief Java Architect at Google
Do you have a favorite puzzler?
I love all of my children equally. No, seriously, it's hard to pick just one, and my answer would vary depending on what day you asked me. But today, my favorite is Puzzle 85 ("Lazy Initialization"), because its behavior is so shocking. I can't say more without spoiling the puzzle. You'll just have to try it out for yourself.
How does this book relate to Effective Java?
I think Java Puzzlers is the perfect companion to Effective Java. To a first approximation, Effective Java tells you what to do and Java Puzzlers tells you what not to do. Once you know what to do and what not to do, you're all set.
Can you say something about the "lessons for language designers?"
Sure. Although this book is aimed primarily at developers, it also has something to offer students of language design. Studying traps and pitfalls naturally raises the question of what design decision led to a particular problem. That's what the lessons for language designers are all about. But as it says in the introduction, they should be taken with a grain of salt. Language-design decisions can't be made in isolation. Every language embodies thousands of design decisions that interact in subtle ways. I think James Gosling put it best when he said that designing a language was like playing Whack-a-Mole: You can squash down a problem in one area of the design, but more often than not, it causes a problem to appear in some other area. So the lessons for language designers shouldn't be viewed as criticisms of the Java platform but as points to ponder.
What's with the fish on the cover of your book?
Ah, the fish... Our friend Akioshi Kitaoka designs brilliant optical illusions. He's most famous for an illusion called Rotating Snakes. It's quite stunning. You look and it, and you swear that it's moving, but it's not. You can look at any part of the picture and it looks still, but the rest of the picture appears to move in your peripheral vision. The underlying phenomenon is known as the stepwise luminance profile variant of the Peripheral Drift illusion (PDF). When Neal saw this illusion, he realized that the shape of a fish lends itself to the illusion, and the orange color has the right luminance to make it work. If you look at the cover of our book in the right light, the outer three rings of fish will appear to turn clockwise, and the inner three rings will turn counterclockwise.
If you guys are really brothers, why are your last names different?
Well, umm... We're not really brothers.
What's with the overalls?
It relates to your previous question, actually. Before we wrote the book, we gave a popular series of talks, each containing eight or 10 Java puzzlers. To make the talks more entertaining, we donned mechanics' overalls and told jokes in the style of Tom and Ray Magliozzi's radio show Car Talk . Tom and Ray call themselves "Click and Clack, the Tappet Brothers," so we called ourselves "Click and Hack, the Type-It Brothers."
Anything else you'd like to tell our readers?
Don't code like my brother.
Java Puzzlers: Traps, Pitfalls, and Corner Cases
FindBugs: Find Bugs in Java Programs
New Language Features for Ease of Development in the Java 2 Platform, Standard Edition 1.5: A Conversation with Joshua Bloch
Effective Java Programming Language Guide
The Java Language Specification, Third Edition