Rating: 
Summary: Nice intro to slightly advanced Java...
Review: The title "Hardcore Java" is definitely overkill. A better one may be "Stuff a new Java developer might not know yet".This book is full is little nuggets of "oh, good idea" and "oh, I never knew that". But don't expect to be a guru after reading it by any means. Lean towards 'Effective Java Programming Language Guide' for a thorough, advanced discussion of the Java language. For it's price, it's not bad, it seems relatively cheap compared to many books on the subject. It's easily a weekend read as well.
Rating: 
Summary: Useful, but not hardcore
Review: There are a few good chapters here, which would have made great articles. The author's experience (and bias) as a C++ developer shows in much of this book, however. Perhaps a better title would have been "A C++ Developer's Hard Look at Java".
Rating:
Summary: Definitely not hard core
Review: When I saw the title, Hardcore Java, I expected that the content would
be so intense, I might not understand much of it. But that wasn't the
case. The book didn't live up to its name.
I think the thing that affected me the most negatively was the
language. For example, the author provided sage advice about not
calling System.exit() from libraries, but felt compelled to add the
following which was longer than the advice: "Just imagine the look of
surprise, consternation, and growing anger on the face of your users
when they try to run the plug-in, and their application simply exits
without bothering to save two hours worth of data. Although it sounds
funny, it could lead to sore feet from looking for another job." While
this might be cute once or twice, it gets tiresome and patronizing
when used repetitively.
The book could have used more editing. I found the text garrulous and
included far too many code samples, samples that were longer than they
needed to be, and samples that repeated themselves. For example, the
author's expose on member classes was 21 pages, while Josh Bloch
offered more detailed and concise information in four pages in "Item
18: Favor static member classes over nonstatic" in his book on
Effective Java.
I strongly disagreed with the author's recommendation about making
helper methods protected, not private because somewhere, someday,
someone might want to subclass your class. I'm in the middle of an
extremely large refactoring job, and it has been complicated because
the previous programmer had the same philosophy. The use of protected
enabled the code to grow coupled beyond belief so it became impossible
to modify one class without breaking dozens of others. Fortunately, I
have Eclipse which helps me find which members are used elsewhere, and
which are not. As I made the latter members private, Eclipse noted
that many of them were not, in fact, used at all. But don't take my
word for it: Josh Bloch in Effective Java also recommends against this
practice in "Item 12: Minimize the accessibility of classes and
members." In addition, making members protected to allow possible
extension is not enough: "Item 15: Design and document for inheritance
or else prohibit it."
I only caught four typos, so I obviously needed to be reading more
carefully ;-).
Now on to the better.
The chapter on the use of final everywhere was interesting and worth
considering, although it seems to me that its use would severely
lessen readability.
The example of a typesafe enum superclass was excellent and we've
already incorporated an adaptation of it into our code base.
The chapter on references was also good, and contained real-world
applications. But the chapter must be missing something as it occurred
to me that if one uses Java's EventListener class, wouldn't their
stuff already use weak references?
While there were a few other nuggets of information here and there,
I'd still recommend Effective Java over this book.
Rating:
Summary: More Anecdotal Evidence Than Anything Else
Review: While the intentions of the book are good, and it is an easy read, I haven't been convinced that the author really knows the JVM and its specs well enough to make the assertions in the book. I get the feeling that it's a collection of anecdotal evidence experiences the author has learned and picked up while programming. While most aren't necessarily wrong, no effort is made to explain the roots of the technique and why the condition is. A lot of the discussion is based on techniques to use to reduce bugs. Also a noble goal. But I haven't seen one mention of Unit Tests at all. With so many programming tips to cut down on debugging time, one would think one of the tips would be, "Write unit tests for everything so you never have to start the hunt and debug process." I'd want a version 2 of this book that is really hardcore. And by hardcore, I mean gives me a tip or pitfall and then goes into the JVM spec or Sun implementation and tells me _why_ I'm reading about this. All in all, 2 stars. This is, though, a great book for beginners.
Rating:
Summary: Overall A Big Disappointment
Review: While there are a few nuggets of wisdom sprinkled throughout the book, there is far too much fluff and error to make it a worthwhile read. As for the good, the earlier chapters have some good advice on good coding practices and detailed explanations of why these are good practices. However, most if not all of this advice is also contained in the book Effective Java by Joshua Bloch. As for the bad, there are gobs and gobs of errors throughout the book and there are at least 3 chapters that are of dubious value in a book entitled Hardcore Java (Data Modeling, Proxies, and the JDK 1.5 overview). And yes the back cover does in fact state, "... you'll master the art of writing and maintaining bulletproof and error-prone code ...". Bottom-line, not recommended.
Rating:
Summary: Decent book for beginner to intermediate programmers
Review: `Hardcore Java' is an easily read book. This is both a strength and a weakness as far as this book is concerned. It covers a lot of topics but suffers from the fact that it gives only simple examples to explain the concepts. The book starts out on the right note in the first chapter, describing the core concepts of Java and common gotchas to avoid in writing robust, maintainable systems in Java. I liked the fact that the author got right down to the advanced concepts like assertions and RTTI in the very first chapter. The second chapter available online at http://www.oreilly.com/catalog/hardcorejv/chapter/ch02.pdf on the other hand contains some deceptively harmful advice. The author is trying to show various ways of using the final keyword to trade logical errors for compiler errors, which in itself is a noble goal. The problem is that the author advises the use of the final keyword everywhere in the code. The final keyword only makes primitives behave like constants and pins down references to objects but not the objects themselves. Using final everywhere in the code makes the code noisy and less readable and does not buy much in terms of avoiding logical errors. It is much better to insist on writing unit tests for the code that flushes out the type of logical errors that the author is trying to avoid. Using final as a Coding Standard is just wrong advice. The chapter does have some good points in places where the author talks about Unmodifiable Collections and final methods and classes. The chapter on Collections is particularly well written. It points out the advantages and disadvantages of using the various Collection and Map classes in the jdk. The chapter is concise and to the point and offers good advice. Other notable chapters are on Constants, and Nested Classes. The chapters on Reflection and Proxies are heavy on theory and light on examples. The chapters can be made more useful with the help of practical examples. Overall the book is good for developers who are comfortable in writing basic Java code and want to learn a few advanced topics. It does not provide much for advanced programmers. A few topics that I wish the author had covered in a book titled `Hardcore Java' are Class Loading concepts and bytecode manipulation techniques.
| 
