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

I enjoyed Java Puzzlers, but...

[Anonymous Coward]

...it took a long time to load the first page. On the other hand, if you drop the book on the ground, it automatically throws itself into the garbage can.

Not interested

[TreeHugger04]

If the title of a puzzle book does not contain the letters s,u,d,o,k and u in it, I am not interested. Sorry.

/. is made of cheese

[fohat]

The problem being that Slashdot Headlines are often either: a) Dupes, b) boring, c) difficult to read, d) poorly written, or possibly: q) made of cheese

To the moon, Java!

Thats the whole point of the "puzzler"

[brunes69]

It is to expose a flaw in the language.

Why should a primitive byte be signed, but not a primitive char?

And why can't I have an unsigned int primitive in Java?

Primitives in Java are a real pain to work with compared to most languages.

Re:Thats the whole point of the "puzzler"

[$RANDOMLUSER]

> Why should a primitive byte be signed, but not a primitive char?

Because a byte is a numeric class, and a char is a character class? Your question is like asking why booleans can't be signed or unsigned.

Re:Thats the whole point of the "puzzler"

[kaffiene]

>Primitives in Java are a real pain to work with compared to most languages.

Bullshit. I've coded through asm, c, c++, java and they all have their own ways of doing things which you need to be aware of. The language is NOT the problem.

Re:Thats the whole point of the "puzzler"

[_xeno_]

What's the difference between short and char in Java?

One is signed, the other is unsigned.

chars are treated just like numbers in Java. You can do numeric comparisons with them, you can add them, you can subtract them, they're just numbers.

By definition, a char in Java is a 16-bit unsigned value. It happens to represent a single UTF-16 sequence, although arguably you could have done that using a short.

But, here, check the language spec. A char is just an unsigned short. That's it.

Re:Kind of

[codegen]

See, to a C coder, this is non-obvious because both the types would be signed, and if you wanted it unsigned you would have to say so.

Sigh... Not true. Wether chars default to signed or unsigned is vendor specific in the ANSI C spec. If you code depends on chars being signed or not then you have to state it explicitly if you want your code to be portable. I have been bitten by this on one important occasion when I was still in Industry and have never forgotten it.

Re:master of the obvious

[AKAImBatman]

Amen. The Java Language Specification states that char IS NOT A NUMBER. It's a character representation and should be treated as such. Thus the entire example is contrived, and makes no sense. It *might* be interesting from the perspective of loading a file (e.g. buffer.append((char)in.read());), except that the IO streams provide Integers to get around the sign problem.

This is why in computer science they have a term for supposed "idiosyncracies" like this: "Garbage In Garbage Out" (GIGO)

disappointed -- try the java cert exam

[SamSeaborn]

I was excited when I saw the "Java Puzzlers" subject heading. But that byte to char example left me under-whelmed.

Have any other more interesting/fun examples?

If you want some puzzlers, look for copies of the Sun Java Programmer certification exam. There's lots of "we're not testing to see if you're a good programmer, just testing to see if you can find the unexpected result in the insanity-pepper code" snippets there.

boxlight

Re:Puzzling indeed

[greg_barton]

Why would anyone use Java?

From now on? Just to piss you off.

Re:Java puzzles? I do them everyday

[Decaff]

Unfortunately, real-life java problems are never very interesting.

Virtually all real-life coding problems are uninteresting. It is nothing to do with Java.