O'Reilly Releases "Java 1.5 Tiger: A Developer's Notebook"

[Jason Menard]

A Crash Course in the Next Evolution of Java
O'Reilly Releases "Java 1.5 Tiger: A Developer's Notebook"

Sebastopol, CA--The next version of Java, code-named Tiger, is more than
just a minor update. With more than one hundred substantial changes to the
core language and numerous library and API additions, developers will have
a variety of new features, facilities, and techniques to master. But with
so many changes, where do you start? You could read through the lengthy
and occasionally boring language specification; you could wait for the
newest 500-page tome on concepts and theory; you could even play around
with the new JDK, hoping to figure things out on your own; or, you can get
straight to work with "Java 1.5 Tiger: A Developer's Notebook"
(McLaughlin and Flanagan, O'Reilly, US $29.95).

This no-nonsense guide by bestselling Java authors Brett McLaughlin and
David Flanagan sidesteps the dull prose and lecture and jumps right into
the jaws of Tiger. Developers will have a handle on many of the important
new features of the language by the end of the first chapter, and be neck
deep in code before they hit page twenty. Through more than fifty working
code samples, they'll get complete, practical coverage of generics, learn
how boxing and unboxing affects type conversion, understand the power of
variable arguments, learn how to write enumerated types and annotations,
master Java's formatting methods and in for/in loop, and even get a grip
on concurrency in the new JVM.

"Whatever Tiger ends up being called officially, it introduces so many new
features to the language that it took nearly 200 pages to cover them,"
note McLaughlin and Flanagan. "You'll find that each page of this book is
dense with code, example, and terse explanation. There isn't any wasted
space. In fact, that's precisely what you're holding in your hands--a
concise crash course in the next evolution of Java, Tiger. By the time
you're though, you'll be typing your lists, taking your overloading to an
entirely new level, writing compile-time checked annotations, and
threading more efficiently than ever before."

"Java 1.5 Tiger: A Developer's Notebook" is set up as something of a cross
between a learning exercise (where you would read from back to front) and
a cookbook (where you can skip around without concern). Developers can
skim the table of contents to find what interests them, but because the
topics are often interrelated they're likely to find themselves browsing
through additional chapters as they put all the pieces together. By the
time they're finished with the book, Java developers will understand:

-Generics, including type-safe collections and defining generic classes
-Enumerated types and values, and their relationship to public static
final constants
-Tiger's autoboxing and autounboxing conversions between primitive types
and wrapper types
-Variable arguments (varargs), including defining your own vararg methods
-Tiger's extensive support for compiler-checked annotations
-The new format() and printf() methods
-The extensive concurrency support in Tiger, including locks, scheduling
timers, uncaught exceptions in threads, and the new Callable interface

"Java 1.5 Tiger: A Developer's Notebook" provides a hands-on introduction
to this important update, presented in a way to help experienced Java
developers bypass pages of theory about the technology and get straight to
work. Part of the new Developer's Notebook series from O'Reilly, this
concise, lab-style guide (printed on graph paper with plenty of margin
space for notes) emphasizes example over explanation and practice over
theory. The book focuses learning by doing, by experimenting with tools
and discovering what works.

Additional Resources:

Chapter 3, "Enumerated Types," is available online at:
http://www.oreilly.com/catalog/javaadn/chapter/index.html

For more information about the book, including table of contents, index,
author bios, and samples, see:
http://www.oreilly.com/catalog/javaadn/

For a cover graphic in JPEG format, go to:
ftp://ftp.ora.com/pub/graphics/book_covers/hi-res/0596007388.jpg

Java 1.5 Tiger: A Developer's Notebook
Brett McLaughlin and David Flanagan
ISBN 0-596-00738-8, 177 pages, $29.95 US, $43.95 CA
[email protected]
1-800-998-9938
1-707-827-7000
http://www.oreilly.com

About O'Reilly
O'Reilly Media, Inc. is the premier information source for leading-edge
computer technologies. The company's books, conferences, and web sites
bring to light the knowledge of technology innovators. O'Reilly books,
known for the animals on their covers, occupy a treasured place on the
shelves of the developers building the next generation of software.
O'Reilly conferences and summits bring alpha geeks and forward-thinking
business leaders together to shape the revolutionary ideas that spark new
industries. From the Internet to XML, open source, .NET, Java, and web
services, O'Reilly puts technologies on the map. For more information:
http://www.oreilly.com

# # #

O'Reilly is a registered trademark of O'Reilly Media, Inc. All other
trademarks are property of their respective owners.

[Doug Dunn]

This is all the hype from the cover. A senior software engineer at Sun Mircosystems (and the author of a very popular book in The Java Series) once told me that technical writers should not bash their competition, but I am going to make an exception here because the Notebook series editor rather arrogantly attacks almost every other sytle of technical writing imaginable.

I paid $30 for this book and found it to be poorly written. It follows in the time-honored tradition of major publishers racing to be the first to market in order to profit from a new release. A quick internet search will save you the cost of this book.

I may be setting myself up for reprisal, but I just hate to see the Java book market abused like this. You work too hard for your money.
[ August 28, 2004: Message edited by: Doug Dunn ]

[Don Stadler]

I've bought both O'Reilly Java titles in the new series and have to concurr with Mr. Dunn about the Tiger book. The Hibernate title on the other hand is a contender for best new book of the year. I liked it a great deal.

[Doug Dunn]

I thought an example would help others to make up their mind. The writer actually recommends the use of switch statements to implement constant-specific behavour rather than the "constant-specific methods" recommended by Joshua Bloch in 1.5 Tiger release documentation. He completely misses the vital point that an enum will not compile unless all of the constants provide an overriding implementation of an abstract method. This effectively avoids the maintenance problem associated with comparable switch statements.

He reasons as follows.

"What about just using a more generic method that determines what to do based on a switch statement? Well, that's a better idea, to be honest. Here's the (much cleaner) way to write OpCode:

...[code example omitted]...

"This is so painfully simpler than the first version of OpCode that I hesitated to even include this lab-but [sic] for completeness, here it is. If at all possible, though, consider using switch in your method bodies to direct program flow, rather than [constant-specific methods]."

Essentially his argument is one of code aesthetics, which makes me wonder if he is even a programmer. Again, he completely misses the raison d'etre for this language feature and seriously misguides his readers.

And then there is the issue of style. I am so sick of reading "How do I do that?" and "What just happened" along with the author's generally condescending tone. For example, at the start of the above quoted section on what he likes to call "Value-Specific Class Bodies" (rather than using Bloch's name of "constant-specific methods"), the author concludes the introductory paragraph by saying: "This is a rather obscure bit of functionality, but sort of cool to talk about around the water cooler." There is nothing obscure about constant-specific methods; they are quite simply anonymous class bodies that implicity extend the enum type.

[ September 01, 2004: Message edited by: Doug Dunn ]

[ September 01, 2004: Message edited by: Doug Dunn ]

[ September 01, 2004: Message edited by: Doug Dunn ]
[ September 01, 2004: Message edited by: Doug Dunn ]

[Doug Dunn]

Okay this is beginning to sound like a "Doug Diatribe" so this will be my last post, but I did want to include the following quote:

"What about...

"...using a class to extend an enum, instead of another enum? That doesn't work either. There's just no getting around this limitation, at least that I've been able to find..[sic]"

A [sidebar] note also says "if you find a sneaky way to extend an enum, let us know! We'll add it to the next edition."

This entire three page discussion of "Manually Defining an Enum" is a complete waste. An enum cannot be extended. It is that simple. The reason why they cannot be extended is explained as follows in the FAQ section of the �A Typesafe Enum Facility for the Java Programming Language� document.

"The semantics of inheritance for enum types is too confusing. People expect subclasses to contain the enumeration constants from both the superclass and the subclass, but they contain only the subclass constants. Further, the compiler generates two static methods for each enum class providing operations on the entire class (values() and valueOf(String)). These methods are defined using the list of constants found in the enum declaration, hence subclassing would break them. More seriously, allowing subclassing of enums would render switch statements ambiguous if multiple subclasses of an enum class contained enum constants with the same simple name. All things considered, the complexity inherent in allowing subclassing is too great to justify it."

The significance of this is that it at least suggest the writer did not even read the available Sun documentation on the subject, relying instead entirely on David Flanagan's research notes.
[ September 01, 2004: Message edited by: Doug Dunn ]

[Brett McLaughlin]

Doug-

First, thanks for taking the time to write something. I'm sure lots of folks would be devastated that another author doesn't like their book; for me, I would rather have a book that is talked about, and even disliked, than one that sinks into obscurity. Some of the best books that have ever been released are loved by some, and vehemently hated by others. I'm not saying this is one (or that it isn't!), but it's nice to see that we're breaking the mold enough to have authors from other publishers feel the need to say something.
As for your Sun friend's recommendation, I think he's right, for what it's worth. You know as well as I do that an author can't be objective about books from a publisher that cuts into his market share, let alone his subject area. I don't know what you write, but I personally avoid (as an editor and author) making reviews or recommendations, unless specifically asked. That said, let me tackle some of your issues:

You wrote:
I paid $30 for this book and found it to be poorly written. It follows in the time-honored tradition of major publishers racing to be the first to market in order to profit from a new release. A quick internet search will save you the cost of this book.

I think you are confusing "poorly written" with "common language." I intentionally don't write in high or academic styles. However, it has been through David Flanagan's eyes (I think we all agree he knows how to write), my eyes (despite your opinion, I've edited over 20 books in the last 24 months, and consistently get the highest grammatical marks), and a professional copyeditor. So it's clearly not poorly written--it's agressively written, colloquially written, etc.... and you're welcome to not like those things. But just because a style doesn't suit you, I'd be cautious about then maligning that style as poor English :-)

That's sort of like me taking shots at the literacy of the "for Dummies" authors. I don't care for the style at all, but that's not the same as it being incorrect in terms of basic English. :-)

You wrote:
And then there is the issue of style. [censored] I am so sick of reading "How do I do that?" and "What just happened" along with the author's generally condescending tone. For example, at the start of the above quoted section on what he likes to call "Value-Specific Class Bodies" (rather than using Bloch's name of "constant-specific methods"), the author concludes the introductory paragraph by saying: "This is a rather obscure bit of functionality, but sort of cool to talk about around the water cooler." There is nothing obscure about constant-specific methods; they are quite simply anonymous class bodies that implicity extend the enum type

As you say again, this is style. Personally, and as many have said to me in person and in mail, this style works. I think it's silly (and a tad bit irresonsible, to be honest) to try and impose your preference of style on others by calling it "poor writing." We have lots of books, at lots of levels, and it doesn't hurt my feelings if you choose a different style/series. What I don't care for is telling others it's poorly written. You're welcome (as another does) to say you don't care for it. At least that's honest!

Your comment about code aesthetics is staggering--it implies that if one codes elegantly, they can't be a "real programmer." Of course, I imagine that you didn't telnet into port 80 on javaranch, and enter your comments into vi or emacs, send it across the wire... then again, I see you used the little gremlins, and that's certainly aesthetic...

Seriously, I'm not trying to give you a hard time. I'm just pointing out that it's silly to make some of the associations you do. And, despite your innuendo, I do just fine programming :-) But, now we're really resulting to cheap shots, aren't we? Seriously, I seem to recall signing up for JavaRanch and having to agree to "be nice".

Finally (I've about droned on all I'm willing to), there's a nice errata page for all O'Reilly books, and I respond to each personally. I have to say that I'm surprised I haven't seen all of these "mistakes" in the errata. I mean, if you're really out to help the community, wouldn't it be useful to post errata and help fix things you think are wrong, rather than just launching into someone on a public forum?

Just seems silly to me... but then again, what do I know? I'm just the guy who wrote "Java and XML", right? I'm just the guy who co-authored JDOM (http://www.jdom.org), helped found Turbine (http://jakarta.apache.org/turbine), was a committer on Cocoon, JBoss, a senior programmer on Enhydra, the creator of Zeus, the guy who wrote the original infrastructure for Nextel Communications' billing systems... but since it's all nicely formatted, commented code (aesthetics), I guess that's not worth much :-)

There... I've got my rant out of me, poorly written and all. I think you've all suffered enough of the sarcasm tonight, so I'm going to go back to writing another book. I look forward to your review of it :-)

And to everyone else, I always welcome your comments. I respect people's opinions when fairly portrayed as opinions, and would love to hear from you, positively or negatively. If you find errors, please please report them over at oreilly.com, so we can help all readers. And...

... be nice ...

:-)

Thanks
Brett McLaughlin

[Bert Bates]

[Mapraputa Is]

Originally posted by Brett McLaughlin:
You know as well as I do that an author can't be objective about books from a publisher that cuts into his market share, let alone his subject area.

In fact, I remember Kathy Sierra recommended Sun Certified Programmer & Developer for Java 2 Study Guide (Apress) rather than her own (McGraw-Hill) to prepare for a developer exam, so I guess it's not that impossible...

[Kathy Sierra]

Originally posted by Mapraputa Is:


In fact, I remember Kathy Sierra recommended Sun Certified Programmer & Developer for Java 2 Study Guide (Apress) rather than her own (McGraw-Hill) to prepare for a developer exam, so I guess it's not that impossible...

But that's only because Max Habibi *paid* us to say that...



Actually, I *do* agree with Brett that a computer book author probably can't be objective about other computer book author's books. There has always been a HUGE gap between what we hear from readers vs. what we hear from authors about *our* books, for example. If I listened only to other computer book authors, I'd have given up by now, convinced that my books are the worst things to ever happen to technical publishing.

cheers,
Kathy
[ September 02, 2004: Message edited by: Kathy Sierra ]

[Mapraputa Is]

Ok, Brett said "his subject area", so there is no disagreement here.

[Warren Dew]

Brett McLaughlin asks for opinions.

As you say again, this is style. Personally, and as many have said to me in person and in mail, this style works. I think it's silly (and a tad bit irresonsible, to be honest) to try and impose your preference of style on others by calling it "poor writing."

In Doug's defense, he at least provided enough information for us (or me, at least) to strip away the spin and identify that what he didn't like was the informal style. That was useful information for me, who also doesn't care for that style - though I agree that some prefer it, including some of my friends.

Your comment about code aesthetics is staggering--it implies that if one codes elegantly, they can't be a "real programmer."

Yes, I found that one pretty amazing, too. I've always found that aesthetically clean code is more legible and far more likely to be correct. Inelegant or ugly code tends to provide lots more places for bugs to hide.

On the other hand, I find it ironic that it's the author who writes books using a colloquial style of English who advocates elegant code, and the one who presumably prefers more concise English who doesn't seem to care about code aesthetics.

[Mapraputa Is]

Frankly, I was a little peeved by what I read as an implication that Doug criticized the "Tiger" book because of "the conflict of interests". My apologies in advance if misunderstood you. Doug's dedication to his own book, his attention (passion would be a better word) to details is exceptional, if not to say unique in our current super-fast publishing business. It's understandable why somebody with such a high level of expectations to his own work would be irritated by what he perceives as lower standards. I didn't read the "Tiger" book, so I don't have any opinion here, but we just had a 10hh review of it submitted, so apparently the book provides a value to at least a part of audience.

[Ernest Friedman-Hill]

Originally posted by Warren Dew:
I've always found that aesthetically clean code is more legible and far more likely to be correct. Inelegant or ugly code tends to provide lots more places for bugs to hide.

But note that Doug's point is that in this case, the aesthetically pleasing code has a specific, well-understood maintenence problem, while the "ugly" code was intentionally designed to remediate this exact problem.

Switch statements and enumerated types are tightly associated in many languages; each case of a switch corresponds to one value of the enum. When a new value is added to an enum, every switch statement that refers to the enum must be updated, but the compiler never gives you any help. it's very easy to forget to update a switch, and you don't find out about your mistake until testing (if you're lucky!)

Constant-specific methods change this dynamic: if you add a new value to a Java enum, the Java compiler will refuse to let you forget to implement a method for the new value. The bug therefore never happens.

Doug's point is that recommending the aesthetic over the proveably correct is irresponsible; in this case, it's missing the whole point of the feature.

One of the JavaRanch staff (I think it was Jim, but I forget now) used to have the signature

For every complex problem, there is a solution that is simple, elegant, and wrong.

which is quite relevant here. Blindly recommending the aesthetic over the correct is simply wrong.

Disclaimer: I haven't read Brett's book, and for all I know Doug has misinterpreted its intent. If Brett wants to send me a review copy, I'll write a review for JavaRanch.

[Kathy Sierra]

Originally posted by Warren Dew:
...to strip away the spin and identify that what he didn't like was the informal style. That was useful information for me, who also doesn't care for that style - though I agree that some prefer it, including some of my friends.

I just wanted to mention something about "informal style". While informal/casual IS definitely a style choice that some will prefer and some won't, the tendency and conventional wisdom is that most technical books *should* be written in a formal style in order to be absolutely precise. This makes sense, of course, but I think it needs to be balanced with arguments in *favor* of a conversational style.

Specifically, a conversational style *can*, for many people, be more conducive to learning than a formal tone for several reasons. And in fact, there are many studies that support this. While many of the studies are specifically targeting text presented in a computer-based tutorial, the principles involved are the same whether the material is in print or on the screen. It's just that the researchers usually had more *funding* to study these effects for the purposes of making better computer-based learning products. Over the last fifteen years, I've found that *most* of the interesting and useful research that applies to writing computer books comes out of the academic and commercial research on intelligent tutoring systems, computer/web-based learning, etc. But again, what's been discovered applies directly to what we're doing in books. It simply becomes more IMPORTANT for computer-based training, because there's a greater need to reduce the number of words that it takes to convey something and have the learning be more efficient.

1) Moreneo, R., Mayer, R.E.,Spires, H., and Lester, J. (2001) The Case for Social Agency in Computer-Based Teaching (Cognition and Instruction, 19).

2) Moreno, R., and Mayer, R.E. (2000) Engaging Students in Active Learning: The Case for Personalized Messages (Journal of Educational Psychology, 93)

3) Mayer, R.E., Sobko, K. and Mautone, P.D. Social Cues in Multimedia Learning: Role of Speaker's Voice (Journal of Educational Psychology)


From the book: "e-Learning and the Science of Instruction" by Ruth Colvin Clark (arguably one of the world's top experts on instructional development/learning over the last two decades) and researcher Richard Meyer:

"In the 2000 study, compared versions in which the words were in formal style with versions in which the words were in conversational style (for a botany lesson). Both versions presented the same information, but in the personalized version the content spoke directly to the learner. In five out of five studies, students who learned with the personalized text performed better on subsequent transfer tests than students who learned with formal text. Participants in the personalized group produced between 20 to 46 percent more solutions to transfer problems than the formal group..."

And...

"Complementary results come from related studies. For example, people read a story differently and remember different elements when the author writes in the first person than when the author writes in the third person (Graesser, Bowers, Olde, and Pomeroy, 1999). "

One of the conclusions in the book is:

"Based on the cognitive theory and research we have highlighted in this chapter, we can propose the "personalization principle": First, present words in conversational style rather than formal style. In creating the script or text for an on-screen passage, you should use some first- and second-person construction to create the feeling of conversation between the course and learner."

These conclusions were *not* related specifically to things like "soft skills", and in fact most of the example in the book were about learning technical/scientific topics.

From Kathy (me):

The general theory, proven from other studies on human-computer interaction, is that when something is written in a conversational style the brain pays more attention because it *thinks* it is in a conversation and needs to *keep up its end*. In other words, when someone is talking directly to YOU (as oppposed to merely lecturing while you passively listen), your brain tries harder to understand the communication.

So, while there are a lot of arguments to be made on the side of a formalized tone for technical resources, there is evidence to support that an informal tone increases learning and retention.

In the end, I think Warren is right that it is a matter of personal preference. I simply wanted to point out that there isn't necessarily an inherent "betterness" about books that adopt a formal style, even though that's been the conventional wisdom. And that in some cases, the tradeoff of *perhaps* some small level of language precision might be worth exchanging for a higher degree of comprehension and recall/retention/application of the content being learned.

And since far more tech books are written in the formal style than casual, I'm just standing up for the underdog. Casual/informal tone should not be treated as the "second-class citizen" of computer book styles, when the goal is comprehension and retention. (For reference books, I think this discussion is less relevant).

Dude.

cheers,
Kathy
[ September 02, 2004: Message edited by: Kathy Sierra ]

[Mapraputa Is]

For new visitors: this thread was moved from the "Blatant Advertising" forum after we hijacked it. The thread to disciss "Java 1.5 Tiger" book is here .

Back to "informal style" problem...

I found that reading texts written in a formal style, full of "correct" terminology, is like reading a text in a foreign language. The difference is that there is often enough direct correspondence between a word in a new and a word in your native language, so it's largely a matter of memorization. When reading texts that introduce you into a new field, you can't translate new terms into anything meaningful yet, so you don't even have a native language. It makes the task twice as difficult, and if the text will be dense with unfamiliar terminology, the reader will be lost quickly.

On the other hand, *after* you mastered new concepts and corresponding terminology, you start to appreciate the benefits of quick and effective communication that concise and precise terminology provides.

And of course sloppy and wordy writing is a totally orthogonal issue, not to be confused with "good" conversational style.
[ September 02, 2004: Message edited by: Mapraputa Is ]

[Kathy Sierra]

I think that's a really useful perspective, Map! I think it'll help me to keep this in mind.

cheers,
Kathy

p.s. thanks for resurrecting the thread

[Jeanne Boyarsky]

Kathy,
That was a really interesting read (about informal writing.) When I was reviewing the developer's notebook, my first thought was that it was really easy to read like the HF books.

[Warren Dew]

Kathy Sierra:

In the end, I think Warren is right that it is a matter of personal preference. I simply wanted to point out that there isn't necessarily an inherent "betterness" about books that adopt a formal style, even though that's been the conventional wisdom. And that in some cases, the tradeoff of *perhaps* some small level of language precision might be worth exchanging for a higher degree of comprehension and recall/retention/application of the content being learned.

I'd point out something further: the arguments you mention in favor of a more conversational style apply primarily to tutorials, and not to reference materials.

I suspect my preference for a more formal style is directly related to this dichotomy. When I buy a book, I normally don't expect to read all the way through it and retain everything. Rather, I'm only looking for key issues that I need to remember, and I try to retain just enough of everything else that I can look it up if I need to. After that, I use the book primarily as a reference, where an informal style costs me time when I'm trying to look something up, and even a small loss of precision can cost me a lot of testing and debugging time.

People who prefer a conversational style may be looking more for tutorials that they can read straight through, rather than for books that can be skimmed and then used as references when needed.

[Kathy Sierra]

Originally posted by Warren Dew:

I'd point out something further: the arguments you mention in favor of a more conversational style apply primarily to tutorials, and not to reference materials.

Totally agree about reference books. That's why my last sentence in that message said:

"(For reference books, I think this discussion is less relevant)."

This is a really good point to highlight, Warren. I really am speaking *only* to books with a specific goal of learning, where understanding, comprehension, and retention are key. But tutorials are just *one* flavor of the many types of learning books.

But it's true that learning and reference books serve COMPLETELY different needs, and I think Warren is absolutely right--when I'm looking at a technical *reference*, the last thing I want to read is a nice *story*

I think the problem is that a lot of books try to serve BOTH needs, and end up serving neither well enough. If I could give any advice to a beginning author, it would be this: figure out exactly which role your book is meant to play--how it can best help the reader--and commit to doing *that* All The Way, while ignoring everything else. I guess it's just one more variation on the "pick one master and serve it well" theme.

cheers,
Kathy

[Thomas Paul]

Originally posted by Kathy Sierra:
If I could give any advice to a beginning author, it would be this: figure out exactly which role your book is meant to play--how it can best help the reader--and commit to doing *that* All The Way, while ignoring everything else. I guess it's just one more variation on the "pick one master and serve it well" theme.

This is one of the reasons that I think the Head First books are so good. They are perfect for learning something because they make it memorable. But I couldn't imagine referring to Head First Java to find the syntax of the switch statement; that isn't what Head First is about.

Doug's books are written very formally but they are not tutorials. I think Doug's point is that a book dealing with language changes should be more formal because it should be used as a reference by Java developers wishing to learn new techniques.

[Bert Bates]

Thanks Thomas!

I gotta throw in my two cents

Amazon lists somethink like 2300 Java books. 2300! Java is a HUGE topic. I think it's really presumptuous to hint that an author can somehow rip readers off. How exactly would that happen? Would the author force readers to buy their books at gunpoint? Bad books sink of their own weight.

I guess my point is that there is no one "perfect" Java book. As I see it Douglas' book targets a very different audience than Brett's book. I know I don't feel that our books compete with either Brett's or Douglas's, they all have different goals.

Let's give readers a little credit; there's a place for APIs, a place for specs., a place for precise references, a place for learning, a place for tutorials... and the readers know what they need, and when.

[Jeanne Boyarsky]

This is one of the reasons that I think the Head First books are so good. They are perfect for learning something because they make it memorable. But I couldn't imagine referring to Head First Java to find the syntax of the switch statement; that isn't what Head First is about.

That's not what the Developer's Notebook is about either. It reads more like one of us was explaining the changes in Java 1.5. While there is a bit of syntax, it is more like what one would write on a whiteboard. The author refers you to the API for any involved syntax/method name stuff.

This is not a reference book. Just for the record, I wouldn't want a reference book to read like this either. But it is a very enjoyable way of learning about the changes.