Customer Reviews

Hardcore Java

5 star:		(4)
4 star:		(3)
3 star:		(6)
2 star:		(10)
1 star:		(3)

 

 

In the preface, the author states that the goal of this book is to transform a developer from the intermediate level to a true guru. In the back cover it even promises that "you'll master the art of writing error-prone (sic!) code", and the reference to "error-prone code" sadly finds its confirmation once one starts reading.

It takes about two chapters to demolish the author's credibility as a guru, and you will be reading the rest of the book with a skeptical eye, doubting every assertion that looks questionable and suspecting that the author is talking well above his level of competence, and patronizing about it too!

The first chapters are an atrocious review of some Java concepts, densely packed with serious mistakes, not typos, mistakes (plenty of typos too).

As an example, on page 9 the definition of the `for' statement is wrong, a simple check of the Java Language Specification would have spared the author some embarrassment.

On page 15 the author gives us wrong rules for labels in Java, and in the same page he confuses the logic of the `break' and `continue' statements, providing also a logically wrong code example, just to screw-up things even better.

I would not know how to describe the section on "Chained deferred initialization" on page 53, "raving" maybe. This one is cited in the errata page at oreilly.com, and the "author regrets that it slipped through the proverbial cracks". I am more concerned that something like that has been actually written (complete with code samples!), than that it has passed unscathed through editing and reviewing. Let's hope it was written by somebody else playing with the author's laptop. Somebody who does not know what JVM means.

There are also less severe but equally confidence-abating points, like, on page 25, the form:

new String("A button to show" + text);

which we should not find in books for guru wannabes.

The author is probably a productive software architect, some points, later in the book, are interesting, though nothing could be defined advanced, but he does not know Java better than an average developer, and this book does not add very much to an intermediate level, apart, maybe, from a warning about writing books: writing a book can transform you from a good developer into a bad author.

It is sad that we are flooded with such mediocre and unprofessional "error-prone"publications from such once reputable publishers, from time to time I still re-read and enjoy the conciseness, clarity and value of classics like K&R's "The C Programming Language" and I wonder why today's output is so vastly inferior.

As one of the few exceptions, I strongly recommend Bloch's "Effective Java" (Addison-Wesley) which is truly a book written by a guru. After reading that one, "Hardcore Java" will seem even emptier.

A typo from the back cover sums things up, "Also, you'll master the art of writing and maintaining bulletproof and error-prone code...". I suggest going to the O'Reilly website and reading the errata before buying.

Another one of my favorite lines in the book is, "The only way to clear an entire bit...". Anyway, why is there a 5 page discussion on bit manipulation in a book entitled Harcore Java?

I wanted to like this book. There is some good advice here, but you have to sift through a lot of text to find it. The first chapter, of 42 pages, contains a lot of very basic beginner type information and could be reduced to:
1. Chain constructors because...
2. Don't hide exception information...
3. Make the default case of an if/else or switch be an assert because...
Discussions about every object descending from java.lang.Object, if statements, ternary expressions, for loops, break, continue, labels, and a reminder that System.exit() causes your program to exit, are misplaced in all but the most basic of books for beginners. That's not how this book is advertised.

The author mentions assert and takes a swipe at a discussion on assert versus the various runtime exceptions. A good opportunity to discuss Design by Contract and how it's core tenants will lead to asserts and NOT IllegalArgumentException (and it's ilk) is missed entirely. This is the kind of information I would expect in a Hardcore book.

The author appears to really like reflection. Too bad there are no good examples on why you would want to use reflection, such as dynamic mock objects, overcoming a few difficulties while unit testing, specific library implementations (making JMS messages look like function calls, for example), etc. Instead we get a toString() implementation, a discussion on beans/introspection, and an example unit test that has very limited scope. The author suggests mayby GUIs could be built using reflection, but fails to expound on this fantasy. Imagine every GUI looking like a simple properties editor. This is not the kind of statement you throw out and don't attempt to back it up. At least the reader is given a warning, although slight, about the performance of using reflection.

The chapter on Proxies is made up of a discussion on the Proxy Pattern and dynamic proxies. The first half of the chapter is a rehash of a well known pattern and there are no reasons given why you'd ever use a dynamic proxy.

The chapter on references covers no new ground. The one example of weak references in listener lists skips over the problem that, often, the only reference to the listener is in the list iteself. Otherwise, Sun could rewrite their listeners and clear up lots of leaks.

The chapter on JDK 1.5 contains some errors likely related to changes made while the book was in production. Anyway, there's nothing here you couldn't find online.

The chapter on immutable objects has good advice. Too bad examples later in the book don't follow the advice. In the section on Constraints the author calls them, "reusable and immutable objects", yet in the very next example doesn't make the private data final. Eat your own cooking before asking us to eat it too.

One last thing, the book is way over priced. It should be $20 and about 150 pages smaller. Of course, then it would have to be retitled, "A Few Java Tips".

This book has many errors, both typographical and factual. A lot of the advice is dodgy, to say the least. My impression is that the author is trying to write beyond his competence level, but at the same times manages to be patronizing. I'm currently preparing a (practically) page-by-page critique of the problems with this tome. I'll publish a link here when I have a substantial section completed. (Note - this goes way beyond the errata published on the O'Reilly site.)

The author of this book recently visited the Java Forums to discuss it and it was noted that he had a misundertanding of the protected scope. That's a pretty fundamental part of Java.

From the sample chapter on the O'Reily site I've come across a few things I find to be poor advice, such as making Singletons extensible and spending time trying to speed up Logging.

Other than that, this book does cover a lot of poorly understood and misunderstood topics in Java. Just don't take all advice in this book as law. A good starting point but there many other schools of thought.

With all the criticism and found errors being correct, junior Java developer absolutely should not ignore this book.

Book is filled up with the good practical techniques and rules of the thumb described in a simple and effective manner. Some techniques, for example use of readResolve method in constant serialization, are explained better and in more practical manner than "Effective Java" does.

Real book's name should be "Practical Java development for beginners"

This book disappointed me. The title raised so high expectations. I started very enthusiastically to read the book and ended in wading through quite a mess.

The level of the book is intermediate, certainly not advanced.

The topics and treatment in this book are quite mixed in level and style. A little about the language itself (so I learned happily about the existence of labels in Java), a lot about the API (here I appreciated most the dynamic proxy and the reference package discussion) and even an entire chapter on design (which I did not like at all).

If you want to learn a little more about Java and have already read the top notch "Effective Java", then this book is full of useful suggestions of areas for further exploration.

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.

I'm a great fan of the O'Reilly books, but this is by far the worst I have ever seen. The book isn't nearly as advanced as it indicates and is full of errors, both typographical and factual. The errata on the O'Reilly website mentions a number of mistakes, but here's a few more that they don't mention.

e.g. Many examples use the following technique for using an iterator in a for loop (page 6 for example):

Iterator iter = list.iterator();
for (String val = null; iter.hasNext(); val = iter.next()) {
// Do stuff with val
}

Do you see the obvious flaw in this technique? val will always be null on the first pass of the loop and the last element in the list will never be processed!

Another example (page 14 I think) is his errornous description of how the break statement works with a label:
(Ignore the dashes, they're just there because Amazon doesn't allow html tags in the reviews).

RESTART: {
---- for (int x = 0; x < 10; x++) {
-------- for (int y = 0; y < 10; y++) {
------------ if (some bad condition)
---------------- break RESTART;
------------ }
-------- }
---- }
}

MYLABEL:

The author states that the break statement will pass control to the label and will start processing the loops again! Rubbish, that's a goto! The break statement will break out of the both (x & y) loops and continue processing at MYLABEL.

These aren't verbatim examples as I was so disgusted with the poor quality of the book that I returned it today (I bought it yesterday).

I usually don't participate in these reviews, except to read them, and I wish I'd read some before buying this book. As a hardcore C++ programmer and moderately accomplished Java programmer, the title lead me to believe I would be getting something along the lines of what Myers and Sutter did for C++. I was sadly dissapointed. While there are a few nuggets in the text, it is also filled with errors and bad advice. Proposing not using anonymous inner classes because they're "not mainstream" and "hard to read", and more telling "not object oriented", tells me the author needs to do a more thorough research before writing his next book. Any technique, when abused or misused can produce bad code, however anonymous inner classes is an elegant solution to a particular problem set, and should be encouraged in those areas, not broadly poo-poo'd. Educate to the right uses, not discourage because "I find it hard to read". This was the diatribe in the book that pushed me to write a review. If you get this book for free, and have a high tolerance level, there are one or two things to be taken from it, however if you are a novice Java programmer, seek input from someone senior before buying into many of the bad pieces of software engineering advice offered by this book.

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.