Java Puzzlers

Kylar writes "When you have spare time and decide to do something with a book (That's like an analog webpage, for the neuronauts among us), how often do you turn to a computer related book? How often has it happened in the last year? Right. The problem being that computer books are often either: a) boring, b) difficult to read, c) poorly written, or possibly: d) made of cheese." Read on for the rest of Kylars' review. Traps, Pitfalls, and Corner Cases - Java Puzzlers author Joshua Bloch, Neal Gafter pages 282 publisher Addison-Wesley rating 9 out of 10 reviewer Tom Byrne ISBN 0-321-33678-X summary 95 Corner cases and traps that any serious java developer should be aware of (or entertained by.)

Java Puzzlers is none of the above(*), being well written, amusing, whimsical, and above all, informative. Bloch and Gafter have brought us a book that entertains us with corner-cases, one-in-a-million chances and other happenings that explore the ins, outs, and guts of the Java Programming Language.

Anyone who has been a serious java programmer in the last several years should know the name Josh Bloch, and more importantly, should have read his book Effective Java. Josh, acting as java's platform architect has been directing and guiding Java into it's current incarnation as a mature, robust (Cue the laughter from the peanut gallery) programming language.

This book primarily references the Java 1.5 programming language, and some of the puzzles are 1.5-specific, although a significant portion of the problems are applicable to previous versions. Also, this book is aimed towards people who are competent-to-expert java programmers, and although there is a lot of good information, people who are new to Java will probably be a bit lost. As it stands, I have 7 years of Java experience, and I was only able to figure out about 15% of the puzzles without resorting to code, or more frequently the answer. The reason that I didn't stop to try out most of these problems is that the book is eminently readable, and difficult to put down (unusual for a computer book, and doubly so for one that delves deeply into a language specification document.)

This book dives into a lot of esoteric bits of the Java Language Specification, also known as "The Big Paper That Sometimes Tells Us Why Java Acts Like That," and there are lots of bits in there that don't even make sense, let alone seem intuitive.

Divided into 10 parts, each part presents a series of different code problems that usually present a small method or class that looks innocuous, but in reality exposes a piece of behavior that is strange, spectacular, or, more often, completely confusing. The book exposes flaws in the language, including one of my personal pet peeves, their inability to have a consistent Date object, and this is noted in Puzzle 62 by my favorite line in the book: "The lesson for API designers is: If you can't get it right the first time, at least get it right the second..."

One topic that I found was a continually recurring theme had to do with handling primitives and what happens when they are cast into different types. Java provides a lot of ways to deal with primitives, and for the most part, they play nicely with each other. There are several occurrences that really surprised me. A perfect example is the following innocent statements:

byte b = -1;
char c = (char)b;

so c=-1, right? Wrong. Places like this are things that you could potentially knock your head against the wall trying to figure out why something doesn't do what it appears to do.
(In this case, byte is signed, char isn't, and the widening cast fills in bits, leaving c=65535.)

A good job is also done describing best-practices for API and library designers, as well as us, the more mundane programmers.

The only downside (from my background and point of view - that of an applications architect, and not generally as a language or API designer) - is that some of the amazing optical illustrations can cause dizziness and nausea - although I can't guarantee that won't happen by the loops and twists that your mind will be tied into because of the puzzles.

Lastly, Bloch & Gafter include an appendix that serves as a summary to all the pitfalls and traps that are introduced in the book, and almost could be an appendix to Bloch's 'Effective Java'.

The bottom line is that in reading this book I learned a fair amount about several edge cases and issues that I had actually encountered - and it increased my understanding as to HOW java does things - although I'm fairly certain that I'll never understand the WHY. And most of all - I enjoyed this book, from start to finish, and that's rare, and worth the time.

You can purchase Java Puzzlers from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Re:How many java apps are you running?

[masklinn]

hint: your browser, email, OS, shell, image editor, spreadsheet, wordprocessor are

My browser and email are actually written in Javascript with a small C core.

Re:Missing Option

[Miniluv]

Thats why I buy technology books instead. If I want a technical reference I use the internet, but if instead I want a book that explains the concepts and assumptions of a specific technology, and then walks through some use cases where the technology makes sense versus some where it doesn't, then it won't go out of date until that whole technology does. I've gotten a tremendous benefit from reading books like this on SANs, performance optimization, various wireless technologies, SIP, etc. All techs that have been around for years, show no signs of disappearing, and none of the books talked about how to implement them using a specific vendor solution, but instead talked about how to evaluate the overall environment and determine if the technology was right.

Re:Interesting? mod this clown down.

[masklinn]

Nope, Gecko is written in C++ but the whole Firefox interface, which is for all means and purposes "my browser" is written in XUL, which is nothing more than Javascript + CSS + XML.

Which is why you can get browsers such as K-Meleon, also based on Gecko and still different browsers (K-Meleon being written in C++/Win32).

Puzzle book is great

[Anonymous Coward]

I bought the puzzlers book on a whim. Love it.

But the subject seems to be "computer books in general", and man is there a world of difference between computer books. Someone might pick up an Organization textbook, and come to understand twos complement numbers (and thus, not be surprised by the puzzler mentioned in the article), he might learn how a full adder can be made from NAND gates, and that might get him to the second chapter of a logic theory book.
It may be tempting to compare "computer books" to "computer books", but "PHP in 24 Hours" is NOT on the same shelf as Cormen, Knuth, Stevens, Hopcroft, Sipser, I think you get the idea.

A person might be very skilled and experienced in some areas, who would pick up one of these books and wonder "WTF?"

Works both ways. I know CS academics who would be hard pressed to function in a business software environment, and experienced business software devs who would not understand the theory expression to any depth, even those who ackowledge that theory is important.

Another Example

[Anonymous Coward]

I've been to one of their talks -- they work at Google, and give occasional tech talks for the other engineers. Here's an example that they actually got from somebody else: it was accompanied by some general banter, and multiple options. (Disclaimer: I don't know if this is in the book.)

public class bad {
    public static void main(String[] args) {
        bad.String s = new bad.String("hello");
        System.out.print(s + " ");
        bad.String t = new bad.String("goodbye");
        System.out.println(s);
    }
    static class String {
        java.lang.String s;
        public String(java.lang.String t) {
            s = t;
        }
        public java.lang.String toString() {
            return s;
        }
    }
}

What does the code above do?

a) Print "hello hello"
b) Print "hello goodbye"
c) Compile error
d) Other

Some banter of my own, roughly:
Well, let's see. This seems like bad code, since why would you name a class String, but sure. So each bad.String has a java.lang.String inside it, and when you construct a new bad.String you get an object that contains the java.lang.String that you constructed it with. Of course, the toString() method just returns the java.lang.String that it stores. So first we make a String with "hello" and then we print it, followed by a space, and then we make a String with "goodbye", and print "hello" again. So I think this program should print "hello hello".

I'll post the answer later if nobody gets it, but you can always try it yourself. I do recommend thinking about it, though: it's cute. Note that everything I said in the banter, except for what I think the answer is, is true.

Re:master of the obvious (SPOILER)

[AKAImBatman]

Hmmm, but proper (internationalized) case conversion is ridiculously more complicated than that.

Yes it is indeed.

The JavaDoc for the Character class actually bemoans this in detail. My only point was that the Java Language allowed the numerical operations for such purposes. Writing a proper Unicode case converter is something that Sun has already done for us. (Thank God.) :-)

And yet it keeps lots of old C syntax which gives you plenty enough rope to hang yourself with (from which flows several of the puzzles).

That much is easy to answer. Java started its life as a new C++ compiler that didn't require a recompile of the entire project when just one class changed. To meet that goal, Gosling turned to using bytecode. That partly solved the problem, but he found he had to make several language changes to keep classes separate. By the time he was done, a new language had emerged.