Slashdot Mirror
Hardcore Java
The two fatal flaws with this book are that it suffers from a lack of cohesion and focus on its audience and that it doesn't present anything new. That the book doesn't present anything new isn't bad if its goal is to summarize, clarify, and educate the novice. But this book doesn't even work for novices because the author has misidentified his audience. At times he writes for the intermediate programmer, at other times he writes for beginners. The confusion over the audience causes the book to leave novices and experts unsatisfied in equal parts.
Detailed Review
Simmons goal is to write a book that helps "transform a [Java] developer from the intermediate level to a true guru." It is his contention that there is a distinct lack of books that target the intermediate to advanced programmer -- his shining exception is the book Secrets of the C++ Masters by Jeff Alger. While I tend to agree with his assessment, I think that he fails for the following reasons: he doesn't stay true to the audience he has chosen and he doesn't say anything particularly new about the topics he covers.
Rather than provide a review of the book as a whole, I'm going to focus on a few chapters and describe what I thought worked and what I thought didn't work. I chose chapters where I thought the author really had an opportunity to distinguish this book from other similar books. At the end of the chapter reviews I provide an overview of the book.
Chapter 1: Java in Review
In this chapter the author sets the stage for the following chapters by providing an overview of the Java concepts that the reader is expected to be familiar with.
The Good:
Assertions are one of the things that a good software engineer should understand and use. It shows good judgement on the author's part to put them at the beginning of the book so the reader can benefit from the author's impressions.
I also found his discussion of initialization to be insightful and interesting. I thought I had a pretty solid understanding of the subject but I was surprised to learn that a field can be initialized by what amounts to an inline method. The author cautions that this technique shouldn't be used often, but he gives a compelling example of when it can be used. It's definitely a trick I'm going to keep in my toolkit.
The Bad:
The first problem is that none of the material in this chapter is necessary for understanding the other parts of the book. Most of it could be reduced to footnotes or sidebars if the author felt it necessary to clarify subsequent topics, but to spend time explaining the importance of the default clause in a conditional is a waste of the reader's time. There's an old saying, "Tell me and I'll forget, show me and I may remember, involve me and I'll understand." The author of a technical book needs to make a significant effort to involve the reader. If involving the reader isn't possible for some reason, the author should, at the very least, show the reader rather than simply enumerating principles divorced from a learning context. Simmons should show us how to use assertions by using them. He does a great job of this with his ubiquitious use of final. I'm less certain of how well he does with his other core concepts. I could go back to the book and look it up, but if I need to do that, it means he's already failed.
The other problem with this chapter is that the author assumes the stance that the reader is a C++ programmer approaching Java. He asserts, "To understand the advanced concepts of the Java language, there are a few core concepts that you must have firmly in mind. Without these concepts, much of this book will not make a lot of sense. The concepts of pointers in Java, its class hierarchy, and RTTI (runtime type identification) are three of the most important on this list." This list might be important for a C or C++ programmer moving to Java (which is a position I'll hazard a guess that the author found himself) but it's marginally useful for anyone else. Allow me to summarize: Java has no pointers, all objects inherit from java.lang.Object, and you can interrogate an object to determine its type at runtime. 'Nuff said.
Unfortunately, this is a theme that runs throughout the book. The author seems to assume that his audience has a C++ background and he either differentiates between the things that Java has that C++ doesn't (e.g., pointers) or he introduces bits from his C++ background that are also in Java (e.g., the ternary operator). The reason for this, I believe, is that the author has failed to separate himself sufficiently from his audience. That's to say, he's writing the book that he would have liked to have read when he was starting his Java career. This isn't a bad thing if you're sufficiently like Robert Simmons, Jr. to warrant that kind of advice, but if you're not, his exposition is going to be hit or miss.
Chapter 5: Exceptional Code
This chapter covers the use and misuse of exceptions in Java. It provides a summary of the different types of exceptions and provides some guidelines for good coding practices.
The Good:
Exceptions are an important part of Java and are misunderstood by a fair chunk of Java developers. The author recognizes this and attempts to provide an introduction to exceptions and show some of the common exception anti-idioms. His discussion on the necessity of the atomicity of transactions was valuable and clear. He shows what happens in the rare instances when a transaction fails midstream and isn't rolled back. He then provides good advice on how to write code to prevent this sort of thing from happening.
The Bad:
This is a short chapter and that's unfortunate because the topic of exceptions is rich and worth much investigation. This chapter provided an excellent opportunity for Simmons to display some virtuosity and say something significant about the subject. If nothing else, he could have elaborated on the relative merits of checked exceptions vs. unchecked exceptions; a topic that has been the subject of Holy Wars in the Java/C# community. Unfortunately, all he really mustered was an, "unchecked exceptions are Java's way of not cluttering up your code with too many 'throws' clauses." (paraphrased, but see the end of section 5.1.1)
The author seems to have some good intuitions around the use and misuse of exceptions, but rather than clearly delineating the issues and sharing his insight with the reader, he sets up a couple of toy examples that show the syntax of exception handling and waffles around the issue of when to use checked exceptions and when to use unchecked exceptions. There is little enough spoken about exception handling that this might be sufficient if Joshua Bloch hadn't already provided a solid grounding in exceptions with Effective Java. But since he has, I had hoped for some new insights, which Simmons failed to provide.
Chapters 9 & 10: Practical Reflection and Proxies
These chapters provide an introduction to Java's capabilities for introspection of types and objects, as well as describing the new JDK 1.4 DynamicProxy class. Simmons also gives some examples of how to write proxies--dynamic and static.
The Good:
In choosing to cover Java's introspection facilities, the author demonstrates that he recognizes the importance of metaprogramming as a qualification of Java expertise. It's on par with things like writing classloaders or grokking bytecode and it separates the gurus from the merely competent. If nothing else, it gives Java programmers the opportunity to do the things that smug lisp weenies are always nattering on about.
The author gives a good overview of how reflection works in Java as well as providing some examples. He also distinguishes between static proxies (like the Proxy pattern in Design Patterns) and the nifty dynamic proxy part of JDK 1.4 and shows how to use these proxies and provides some demonstrations of how they can be used.
The Bad:
As with much of the book, the examples aren't particularly compelling and Simmons doesn't take the opportunity to take the reader to the next level and show him some sweet metaprogramming. Reflection and proxies aren't complicated conceptually, and the syntax is fairly straightforward. He could have gotten the implementation details out of the way and then provided examples from the field. The JMock guys are doing some nice work in generating mock objects for unit testing with dynamic proxy and the Nanning guys have a nice aspect-oriented programming framework that uses reflection and proxies. This is the kind of work that's being done with metaprogramming and confining the discussion to toy examples is discouraging.
Overall:
The Good:
The author has a good conversational style and seems like the kind of guy that you'd enjoy working with--friendly, knowledgable, and genuinely enthusiastic about his subject. The book has plenty of interesting material. The use of final is a great way of turning logic errors into compiler errors. A knowledge of metaprogramming is becoming more important every day, and bringing metaprogramming to test-driven development is an idea with considerable merit.
Someone new to Java could use this book as a sampler of some important ideas in the practice of Java programming and explore the topics in greater depth at a later point.
The Bad:
This book suffers because the author identified his audience and stated his goal and then didn't follow the path he laid out. As a result, the author winds up disappointing all readers. The novice will find that the author glosses over topics that are clearly over their heads, while the expert will be bored by the level of detail that the author devotes to relatively simple topics.
Additionally, the examples are so simple that a newcomer to Java will not have trouble following them, but someone who has used Java for more than half-a-dozen months will find them uninteresting and unchallenging. The author should have taken the opportunity to really explore the space.
Conclusion:
While this book covered some interesting and high level java topics, it covered them shallowly and its content was presented inconsistently to readers of varying levels of expertise. The author needed to stick with his audience, choose topics that fit well together, and challenge the reader. That said, I don't lay the blame entirely on the author. His editor should have made the book tighter, more compelling, and more focused on its central thesis: helping intermediate Java programmers become expert Java programmers. The technical reviewers, who are presumably experts, should have provided the feedback that Simmons needed to raise the bar.
The book would be more appropriately titled, Robert Simmons, Jr. Shares Some Cool Things from Projects He Has Worked On. I think the best thing for this book would have been for the author to cull each chapter down to one quarter of its existing size and then publish them separately as magazine articles.
Alternate Sources:
The Java Programming Language, 3ed and Effective Java together cover nearly everything in this book in much greater detail and with better authority. Ken Arnold and James Gosling are two of three authors for the first book, and Joshua Bloch, author of the java.util.Collections classes is the author of the second. If you've mastered the material in these two books, you're an expert, full stop. Unfortunately, these books don't really cover reflection and proxies. If you're an intermediate java programmer and you want a good overview of proxies and metaprogramming in Java, I recommend the source code for Nanning, a lightweight aspect-oriented programming framework for Java.
Alex Garrett is a contract programmer who mostly works with Java. For a while, he was the acquisitions editor for Manning Publications, which inclines him to be a smug publishing weenie. You can purchase Hardcore Java from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
Anything that people feel the need to go out of their way to label "hardcore" isn't.
The two books that he recomended look good on Amazon (they both reviewed well). I find it interesting the both of the books are from the same publisher. (note that I am not a amazon partner) The Java(TM) Programming Language (3rd Edition)
Effective Java Programming Language Guide
Nanning
The grass is only greener, if you don't take care of your own lawn.
The term hardcore is also applied on musical genres that are supposed to be harder and/or faster. First there was hardcore punk (think dead kennedys and black flag), 10 years later it was hardcore techno and "happy hardcore" (big, funny hat included).
With that said, hardcore java is not an impossibility, since it's based on context.
Hardcore Java might not be as h4r6c0r3 as assembly, but that doesn't mean that the title should be ignored or that there is simply no such thing as "hardcore" java.
Harcore Java to me means writing Class Loaders or Security Managers, bypassing encapsulation or field and method visibility with reflection, choosing the right garbage collector for high performance server-side applications, dissecting the binary class file format, creating post-compilation class "enhancers" like JDO uses, etc.
These are things that are beyond your typical Java novice, and I would expect some mention of some of these level of topics in any java book labeled "hardcore".
So far from ignoring the title, if this book is more for novices than experts, I'd say the title might be misleading. But if I ignore the first few sentences of your review I might find it less biased and more useful.
Unless you have a really good reason (such as writing an IDE), don't do this:
bypassing encapsulation or field and method visibility with reflection
this:
dissecting the binary class file format
or this:
creating post-compilation class "enhancers" like JDO uses
Using the reflection libraries to get around visibility means you're just begging for a maintenance headache in the future.
Dissecting the class file format to see how a particular compiler translated your code can be a useful technique, but you can't depend on the output being the same when you use different compilers on different platforms.
Modifying class files after compilation is also a good way to give yourself a lot of headaches when things go wrong. It becomes very difficult to determine the cause of any problems. If you need to build classes like this, you should either generate Java code and compile that (like most JSP compilers), or use aspect-oriented programming tools like AspectJ.
VB.NET actually isn't that bad. Fully OO, fairly intuitive language structure, and as fast as C#. There are worse things to be forced upon you.
Or, as the author of the OO system said, "It is actually rather easy to implement an OO system in a functional language."
And the Microsoft Official .Net SDK is free as in beer as well ...
... as long as you're running their non-free, proprietary operating system.
(Score:-1, Wrong)
Well sort of... They have hardware interrupts which really complicates things. Not to mention that for nearly all intents and purposes, they have enough memory to be treated as a TM.
Anyway, the entities you manipulate in Java are quite assuredly not pointers.
If people defined their terms, there would be alot fewer arguments in the world.
According to the Java specification, Java references are pointers. What you are saying is that Java does not have C style pointers. There are definitions of "pointer" at different levels of granulairty. Java has pointers if using a more generic definition of "pointer".
Mono and DotGNU as pure compilers are fine, but are "not there yet" as runtimes. Rotor is interesting but feature incomplete. I suppose we're talking about two different things here, I don't think C# has much value as just a language, so I was speaking of it in combination with the runtime (the real value, IMHO). The only production quality runtime at this time is the official Microsoft SDK.
I like C#, don't get me wrong. But until Mono stabilizes (some areas have, yes, but much work is left) it's going to remain a tool primarily used in the non-free world.
As far as the original point is concerned (that is, C# is a valuable invention), I agree 110%. I use both Java and C# professionally, and for a recent project involving COM automation, C#/.NET was a great technology. However, for general development I feel I have a lot more freedom (primarily wrt deployment) when using Java, and prefer it for that reason.
(Score:-1, Wrong)
All physical computers are equivalent to finite state machines, due to the fact that their memory is not infinite.
A computer with 64 megs of RAM along with 8 32-bit registers has a total of 536871168 bits of memory. Hence, such a machine can take on a finite number of states, namely: 2^536871168 states.
It's a collossal number of states, but the fact is, all computers with finite memory are finite state machines.
First he claims that anonymous inner classes are not 'mainstream Java syntax'. Huh? He's got a fairly awkward definition of mainstream if that's the case.
Second he rejects anonymous inner classes for GUI event handling, instead recommending making the the containing class implement XXXListener. I'll accept that they're two competing idioms, but his only argument is that his way is more readable. I think there's serious room for disagreement there (especially as the whole point of the anonymous inner class idiom is to keep the event handling code close to the control code.)
template
void swap(T& a, T& b)
{
T t = a;
a = b;
b = t;
}