Java has quickly become one of the most important languages in programming, particularly for professional and enterprise-level projects. From its infancy as a language primarily used for web applets to its maturity through servlets, Enterprise JavaBeans, and database access, Java has become a complex and robust tool for today's developer. Hardcore Java takes this language and breaks it apart, piece by piece, revealing the important secrets and tricks that will take you from a junior-level programmer to a seasoned and expert developer. You'll fly through the fundamentals and quickly find yourself learning about advanced memory management techniques, optimization and bytecode-level enhancements, and the techniques required to build lightning-fast GUIs. Throughout the book, you'll also master the art of writing and maintaining bulletproof and error-proof code, all while grasping the intricacies of the Java language. Hardcore Java covers:

• Use of the final keyword to optimize and protect your Java classes.
• Complete and thorough coverage of all types of nested classes, including how to optimize anonymous and inner classes.
• Detailed discussion of immutable objects, including unique tips on when to use them (and when not to).
• Elimination of bugs through exception-handling management.
• In-depth studies of constants, including their impact on the Java memory model.
• The most thorough discussion of reflection in print, moving far beyond other books' "Hello World" coverage.
• Construction and use of dynamic proxies, in both Java Standard and Enterprise editions.
• Expansive coverage of weak references, including usage patterns and their role in garbage collection and memory management.

Hardcore Java is an invaluable addition to every programmer's library, and even the most advanced developers will find themselves moving beyond their own conceptions into truly advanced applications of the language. Thousands of lines of code, heavily commented and easily runnable, illustrate each concept in the book.

Rating:

Rating:

Rating:

Thoughts after Finishing the Book,  August 24 2005
Submitted by Etienne   [Respond | View]

Before I started reading the book I had high expectations: wow, a book from O'Reilly called 'Hardcode Java', that must be good! Unfortunately, the book was a big disappointment for me. It has nothing to do with Hardcore Java - buy Java Puzzlers or Effective Java by Josh Bloch if you want Hardcore Java from a real expert.

The book contains multiple code sample errors, but which book doesn't... What really disturbed me are all these advices the author tries to give, although most of them I can't agree with at all and some of them I would even call 'bad practices' (many of his advices are also in contradiction with Josh Bloch's arguments). The repeated complaints about why Sun made certain decisions is also annoying and this attitude seems quite arrogant to me.

I'm sorry to say but, in my opinion, if you're an advanced Java programmer, this book won't take you to the next level nor will it provide you new insights :-( But read and decide yourself.



rebalancing in the proper direction,  July 12 2005
Submitted by developer   [Respond | View]

The author felt the need to 'rebalance' the reviews. I feel that need also.

Read the errata before buying this book. I read a review on Amazon (check those reviews before purchasing) where the reviewer said that with some scissors and paste and a print out of the errata, this book is good. I find that rather amusing.

Other than that, there's nothing in this book that you can't find out by reading articles on the web.

This is one of the most consistently panned books. Most of the praise is lukewarm.

If you want a good book, get Josh Bloch's "Effective Java".


Hardcore Java Review,  May 18 2005
Submitted by Anonymous Reader   [Respond | View]

I have to be honest - Regardless of your view, voting to 'balance out' a negative review of your own book looks very cheap.

Even if you don't agree, then feel free to reply to HIS comment with your point-by-point replies, but when you feel the need to taint your review ratings to get a better rating - that looks very poor, regardless of your intent.


Should be called "Smart Java",  September 21 2004
Submitted by Anonymous Reader   [Respond | View]

Thank you for the nice review. Please let me know if you have any suggestions on things that you didnt like. =)


Should be called "Smart Java",  August 10 2004
Submitted by Anonymous Reader   [Respond | View]

After reading this book, the first thing that came to mind was that the book was probably titled incorrectly. In my opinion, there is nothing “hardcore” in this book at all. Instead, it should be called Smart Java, because it contains many smart practices to follow in your Java programming. These are practices that every Java programmer needs to know in order to write rock-solid Java programs. Therefore, I recommend this book to any Java programmer.

Many of the chapters focus on coding techniques that can be used to prevent run-time logic errors and instead letting the compiler catch your mistakes for you. These techniques can save a tremendous amount of time because it is easier to track down errors at compile time rather than hunting down the bug when the program runs incorrectly. These techniques reminded me of similar techniques I used to follow as a C++ programmer that sort of got lost on me when I started programming in Java. Some such practices include using keywords such as assert and final. There is also a good chapter on techniques for declaring constants to make your code type-safe.

There are a few chapters in the book that I wasn’t particularly interested in learning about. For instance, the chapter called “Data Modeling” seemed to not quite fit with the rest of the book. It involved more design practices than coding practices. However, I’m sure these chapters may be useful to some programmers out there.

The last chapter of the book discusses the new JDK 1.5 and the new features that it will offer. The author does a good job of explaining these features, and how the next version of the JDK will make Java an even better language than it already is. Some of the new features even make some of his earlier suggestions in the book outdated. This chapter provided a good end to this book because it will allow the programmer to make full use of all the wonderful new features of the new JDK once it is finally released.

Overall, the book was quite good. There were a few chapters of the book that didn’t quite seem to fit the theme of the book, but they still provided intelligent insights into Java programming. There were spelling errors sprinkled throughout, but nothing that really caused misinterpretation of the author’s points. As I said before, I would highly recommend that all Java programmers read this book! Even the most hardcore of programmers may learn a thing or two!



A few good chapters, but...,  May 18 2004
Submitted by Tom Ball   [Respond | View]

I had high hopes purchasing this book, as its title combined with its chapter list promised a good read. I was pretty disappointed at the end, especially since the last chapter is by far the worst.

"The Final Story" chapter made some good points, but those could have been made in much less than thirty pages. The "Immutable Types" chapter should be skipped, as Josh Bloch describes the issue much better in "Effective Java". The "Data Modeling" chapter would make an excellent magazine article (or series even), but is completely out of place in this book.

But there are some good bits, too: the "Nested Classes", "Practical Reflection", "Proxies" and "References in Four Flavors" bring light to poorly understood topics.

The "Tiger: JDK 1.5" chapter is a disaster, because the author's arrogant attitude across strongly as he makes several false statements. It's puzzling, for example, how a reflection guru claims that all of the generic type information is stripped during compilation -- didn't he notice all of the new classes and methods in the java.lang.reflect package for 1.5? Didn't he realize that the compiler needed type signatures for the Collections classes his samples extended?

Then there's the whining, such as his claim that Sun rejected all proposals to implement runtime safety. This complaint ignores all of the other people on the JSR-14 expert group who participated in those decisions, including one of the original authors of the gjc compiler. The Java community has been reviewing the generics proposal since May, 1999, and perhaps the author could have better spent his time participating then.

So take this book with a big grain of salt (perhaps on the rim of a marguerita glass): it makes several good points, but you have to filter out the author's biases much more than other O'Reilly books.


every programmer should understand these concepts,  May 12 2004
Submitted by aFuqua   [Respond | View]

Don't let the name fool you: except the last chapter on Tiger JDK 1.5, there is nothing hardcore about it. Every Java programmer should understand all the concepts in this book. Read the table of contents and buy the book if you aren't completely comfortable with each topic.



Hardcore Java Review,  March 30 2004
Submitted by charles McGuire   [Respond | View]

This book was great! Very easy to understand. Intelligently written. I give it a 5 out of 5!


Hardcore Java Review,  March 30 2004
Submitted by Jim May   [Respond | View]

Great Read!


Hardcore Java Review,  March 30 2004
Submitted by Grayson   [Respond | View]

Informative but certainly not strictly for the hardcore. If you wish to know java in and out, don't be afraid to give this book a shot. I've gone through it twice now to brush up, and a few of my friends have borrowed it, only to wander off and buy their own when I threatened them with dire consequences if it wasn't returned. Good job.

PS: Don't let the jerks get you down, anonymity doesn't always lead to good people doing bad things, in forums or otherwise.


Hardcore Java Review,  March 30 2004
Submitted by P. Sander   [Respond | View]

This book was recommended to me by a colleague and I found it definately worth reading.

Saved me hours of frustrating try-outs.

Would recommend it to any programmer.

Written in a clear and easy to read language that drags you right through the pages.

P. Sander

Germany


Hardcore Java Review,  March 30 2004
Submitted by Jack Valentine   [Respond | View]

I thought this book didn't cover the object oriented nature of Java and I feel I have wasted my money.


Hardcore Java Review,  March 30 2004
Submitted by Jertsy   [Respond | View]

I’m studying java at the moment, Just like everyone else new to the world of Java I’m finding a hard path to walk. But this book had helped me out no-end. I whole-heartedly recommend this book to one and all.

Well done!!


Hardcore Java Review,  March 30 2004
Submitted by Jay   [Respond | View]

I've been learning Java on and off for a couple of years now, and decided to get back into it. I'm about half way through this book and I've found it to be quite helpful. I've learnt quite a few small hints and methods for doing things that I would never have thought of on my own without loads of debugging. Recommended.


Hardcore Java Review,  March 30 2004
Submitted by Josh Osmer   [Respond | View]

Decent Java book. There are so many on the market now though, it's hard to determine where it lies amongst the others. I gave it a good ranking as it was pretty easy to follow.


Hardcore Java Review,  March 30 2004
Submitted by tehuberd00d   [Respond | View]

the best book i have ever read bfrore!!! i didnt like java first ( cause i thoughtt c++ owns everything! ) but hey, this book change my mind and the way of my life!!!


Hardcore Java Review,  March 30 2004
Submitted by Robert Simmons   [Respond | View]

I felt compelled to write this review/response to balance out the situation and address the unfounded review of a person who didnt even read the book. For this reason I gave 5 ... uhh ... gnus ... to balance out the numbers somewhat. I respectfully suggest that reviewers read the book before posting reviews.

<blockquote>

1. common mistakes (ch1)

only 2 of them !

the talk about if, if, else is a programming issue not a java issue

how about if(name == "dave") thats a common java error

</blockquote>

These are only common mistakes that generally did not fit in other chapters. I could have easily entitled the section Miscellaneous Commons Mistakes. The entire book is about common mistakes. The one you are referring to is addressed later in the book.

<blockquote>

2 collections

"override hashcode becuase if you dont you will get bad bucket distributions" This is totally wrong - java.lang.util.HashMap specifically guards against poorly randomized hash codes. THis is a terrible piece of advice since it will make people move from the default hashing system (which is highly tuned to be efficient) to one in which most people will generate poor hashes (probably slowly)

You MUST override hashcode and equals in pairs. And you MUST do it if your object semantics are not those of object identiy. I.e it is posisble that for your class objecta == objectb based on their contents. So if the object represents an Order then you need to hash and do equals check on the order number.

</blockquote>

Again, the duality of hashCode() / equals() is tackled later in the book. Second of all, hashCodes() are also addressed quite deeply. The default hashcode method on java.lang.Object generates a hash code based upon the memory location of the object. This is NOT a good hash code to keep and I can give 10,000 other references of people that agree (not least of all Bloch). Hash codes should be indicative of what is inside the object. Furthermore, when you override equals you must override hashcode and overriding it to refer to the base class method would not be a good idea at all.

<blockquote>

3. Avoiding putting junk in collections

THe solution proposed is classically a bad design. The user of the customer class was able to 'corrupt' the orders set. This is because its the wrong design. You are exposing your inner plumbing to the caller by returning a naked Set. Either return an instance of CustomerOrders and have add(Order order) on it or have an addOrder(Order order) on the Customer object. Have the compiler do the check for you (as you advocate somewhere else)

</blockquote>

Generating types is one potential solution to the problem. Unfortunately it leads to a lot of code bloat that java can not well afford given its performance. It is also difficult to maintain unless you are using a generation mechanism. Returning unmodifiable collections is a low-cost, high value solution. However, it has more impact than merely preventing junk in the collections. It also has the advantage of firming up encapsulation. Even with the advent of generics (which makes putting junk in collections not impossible but more difficult) returning unmodifiable collections is still a good practice.

<blockquote>

These were the first threee things I read - I stopped reading after that

</blockquote>

I respectfully request and submit that you should have read further, indeed the whole book, before making a review. Its quite easy to glance through content of a book and find parts you dont like. Furthermore, it is always easier to crab other people's work than to put up your own to be crabbed. Therefore you should be careful what you say about other people's work.

I think that if you read further in the book, you might find many of your questions answered and you might learn many things you never considered before.


Hardcore Java Review,  March 25 2004
Submitted by Paul Moore   [Respond | View]

I had been waiting for this to come out - either for me or for my dev team. Will not be recommending it though - its useless

1. common mistakes (ch1)

only 2 of them !

the talk about if, if, else is a programming issue not a java issue

how about if(name == "dave") thats a common java error

2 collections

"override hashcode becuase if you dont you will get bad bucket distributions" This is totally wrong - java.lang.util.HashMap specifically guards against poorly randomized hash codes. THis is a terrible piece of advice since it will make people move from the default hashing system (which is highly tuned to be efficient) to one in which most people will generate poor hashes (probably slowly)

You MUST override hashcode and equals in pairs. And you MUST do it if your object semantics are not those of object identiy. I.e it is posisble that for your class objecta == objectb based on their contents. So if the object represents an Order then you need to hash and do equals check on the order number.

3. Avoiding putting junk in collections

THe solution proposed is classically a bad design. The user of the customer class was able to 'corrupt' the orders set. This is because its the wrong design. You are exposing your inner plumbing to the caller by returning a naked Set. Either return an instance of CustomerOrders and have add(Order order) on it or have an addOrder(Order order) on the Customer object. Have the compiler do the check for you (as you advocate somewhere else)

These were the first threee things I read - I stopped reading after that

See larger cover