This review covers The Java Programming Language, 4th ed. by Ken Arnold, James Gosling, and David Holmes. Stoughton, MA: Addison Wesley, 2006.
From the preface: “This book teaches the Java programming language to people who are familiar with basic programming concepts.”
Coverage: The book makes a great attempt at covering the basic topics you need an understanding of to make good use of the language.
Authority: The book’s description of how the language works is solid. (If, like me, you’ve ever experienced one of those programming books where the author’s statements about how the language works tend to be on the level of “I ran a simple test on my PC and hastily draw the general conclusion that it works like X, but I don’t know any of the edge cases or caveats”, you’ll appreciate this!)
Tone: The book’s tone is not condescending. Instruction and tips are presented in a respectful, matter-of-fact tone that doesn’t
Guidance: The book not only tells what’s possible with the language, but offers advice at times on what things might or might not be a good idea (for example, the subsections of 23.3 on Shutdown; and the footnotes on page 42, 206, 428).
Honesty: The authors aren’t afraid to occasionally say “Java does X because of a design error that at this point cannot be fixed”, or to note something that isn’t necessarily the cleanest but is there for historical reasons (examples: the spelling of Cloneable (section 3.9.1) and the footnotes on pages 85, 184, 326, 391, 408). I find that refreshing.
Shows where you need further study: For instance, in the second paragraph of section 14.10 talking about the Java memory model, the book’s explanation of when one thread’s change to a variable is or is not guaranteed to be visible to another thread with or without synchronization made me realize that I need to find a good book just on Java concurrency to master this area.
Helped me see the big picture: A lot of work has gone into the design of the Java language, and while there are a lot of details in the book, it didn’t neglect the big picture. The book helped me see some of the things the designers were trying to accomplish with the language.
Makes you think about design: Beginning to see the big picture (see previous point), I also saw areas where the design of the Java language is not mistake-free, or where its designers made decisions I think I disagree with. For instance, was it a good idea for the containers to implement a fat interface and throw UnsupportedOperationException on certain operations? It seems to me it would have been cleaner to honor the Liskov Substitution Principle (PDF) and slim down those fat interfaces to what each collection type really must support.
Describes the old kitchen sink: The book spends a fair amount of time covering such topics as the legacy collections. These legacy-but-not-deprecated aspects of the language are important to understand so that you know to prefer their newer replacements and can effectively read and work with code using these older constructs.
Index: A big ol’ honkin’ index. Nice!
Thick: Not a quick read.
Not a One-Stop Shop: Even at 760 pages not counting the index, the book doesn’t go into enough detail to confer expert knowledge of all the topics it covers. For example, after reading the concurrency chapter, I mainly realized that this is a topic that I’ll need to study more.
Describes the old kitchen sink: The book spends a fair amount of time covering such topics as the legacy collections. I listed this as a positive, but it’s also a negative — it’s distracting if you want to concentrate on learning how to do things the new way.
Doesn’t take testability into account: This is my biggest beef with the book. Language constructs such as
protected are discussed with a view toward what you’re enabling extending classes to do or preventing them from doing — and that’s good! But the book says nothing about how such design may affect the testability of the code, and it’s easy to accidentally write untestable code using some of those language features (see Michael Feathers’ Working Effectively with Legacy Code, Chapter 10). So, you need to bring your existing knowledge of writing for testability with you and use discernment when the book recommends a design style that might result in difficult-to-test code.
This is a very strong book, which I heartily recommend. Some might chafe at the somewhat slow pace, but I appreciate the book’s thorough coverage of language features and inclusion throughout of consequences, trade-offs, and caveats to know about. For topics such as concurrency that the book did not cover in sufficient detail for me to use well, it gave enough detail to help me realize that I need further study on that topic. It was written by folks who understand what they’re talking about, and it’s now my primary Java reference.