Slashdot Mirror
Effective Java
Introduction
Effective Java is a book very much in the style of Scott Myers' earlier C++ "Effective" series. The book contains 57 individual snippets of Java wisdom, broadly categorised into 10 sections including Classes and Interfaces, Exceptions, Threads and Serialisation. Scott Myers' books are classics; I was interested to see how this would compare.
The author, Joshua Bloch, has been involved in writing many industrial-strength Java libraries. His background is very much evident, in this, his first text. He consistently demonstrates the virtues of favouring libraries, clean APIs and advance design. I found the author very readable, and able to make a convincing argument, even in his more 'controversial' pieces. As with Scott Myers' books, there is a real-world, rather than purist approach taken to the language, with most of the code examples having a real-world feel to them. This is a breath of fresh air when lots of programming books tend to use more contrived examples.
The items
The author has endeavoured to keep the book accessible to less-experienced programmers throughout, while providing food for thought for the more advanced reader. For the most part this is succesful, but a small percentage of articles tend toward the simple side. Examples include 'Minimise the accessibility of classes and embers,' 'Write doc comments for all exposed API elements,' and 'Know and use the libraries.' We've all heard this advice many times and I don't feel that these add value. The vast majority however, are pitched at the right difficulty level. The selection of items is well balanced and broad, although unfortunately there are none pertinent to GUI programming.
Many of the articles are fundamentally based on known design patterns and idioms. Although a useful index to these patterns is included, I would have liked to see the virtues of design patterns summarised and demonstrated to a greater extent, perhaps in the introduction.
I was highly impressed with all code examples. Where used, they are consistently short, relevant and concise, with more verbose examples included on the website. The chosen code examples only ever assist in explaining complex concepts clearly.
The strongest area of the book for me was the section on threading. The author clearly demonstrates, for instance, how overuse of synchronised methods can lead to deadlock. He also provides food for thought on how the thread scheduler might trip us up. A section on moving from C constructs, which initially struck me as an odd category, proved very interesting and thorough. 'Replace enum constructs with classes' is a particularly interesting item, demonstrating the fragility of C enums, and indicating why the often-used replacement in Java (a bunch of public static constants) suffers from the same failings.
In conclusion
Ideally I would have liked to see some of the thinner items removed, and perhaps replaced with a section on the GUI libraries. I also liked the short prose sections, and thought the author could have spent more time setting out his stall before launching in to the items. Having said this, this is one of those rare books which could help a good programmer become an excellent one. Many of the books currently out there are aimed at either the beginner or the guru, and this book fills a gap.
I find this style of book very useful, in that I could foresee meeting the vast majority of the described situations at some point or another. So long as you aren't looking for tips to help you with your GUIs, this title is more than worth the investment.
For anyone interested, those sections in full:
- creating and destroying objects
- methods common to all objects
- classes and interfaces
- substitutes for C constructs
- methods
- general programming
- exceptions
- threads
- serialisation
You can purchase Effective Java from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
J. Bloch wrote the collections framework. His code is clean... I mean, really clean. Given the author's credentials, I suspect this'll stand out in the vast ocean of Java lit...
Have you actually used it lately? Speed has been the biggest improvement. Sure, it used to be slow as hell, I concur, but with Java 2 (1.4) it is wicked quick. And for windows apps, it's far better than VB in at least one aspect - grids. Java has a grid object that works the way you'd want it to, resizeable, sortable, column-rearrangeable... And for data drive apps, this is a major thorn out of my side.
How are you going to keep them down on the farm once they've seen Karl Hungus?
I've found ODBC-style data access in Java to be only slightly less painful than doing it in Visual C++.
I'm in a similar situation, developing and maintaining a data access application in VB6 that has reached 'critical mass', has gotten too big for it's britches, and needs to be rewritten from the ground up.
I've been doing a lot of thinking about what it will be rewritten in, and so far C# and VB.net are leading the pack. All Java has to offer me is some platform independence, which is pretty much irrelevant in my particular case, and I doubt it would be worth headaches like throwing out all the code that's written.
Anyways, this is all contingent on the dorks in marketing not selling imaginary software that I have to write 2 weeks before shipping, that I may have time to make the actual software work.
I don't need no instructions to know how to rock!!!!
... is the Java 2 Performance and Idiom Guide (ISBN:0130142603), by Craig Larman and Rhett Guthrie.
The main things I hate about Java are its verbosity and its enforced and contrived structures.
Except that verbosity and (contrived?) structures goes a long way towards keeping source maintainable. By requiring this verbosity and not to mention strongly recommending the Sun Java coding standards + Javadoc, code becomes magnitudes easier to read. Sure, it adds work and a bit of pain to the original coder/programmer, but adds substantially more ease of use for those down the line. Don't get me wrong it's still very easy to write hard-to-read-and-or-maintain code, but it's a bit easier to go the correct route.
But if that's how you get your kicks, gagged and bound with Sun sticking it to you, then so be it...
That depends on what you are referring to. You are right that Sun tends to stick it to the end user now and then and ultimately Sun can be said to be Java's worst enemy. For example, Mac OS X trying to do some amazing things with Java showing how it can be used viably, getting very little support from Sun.
After all that's said, I too still prefer C++ (even C#) over Java, but just not for the reasons mentioned.
----- "Blame the guy who doesn't speak English." -- Homer J. Simpson
This book is the best resource I've encountered for someone who knows the Java language, but wants to master its use. I can virtually guarantee that the rules and techniques covered in "Effective Java" will form the new foundation on which you will build the rest of your best practices for writing excellent Java code.
Written by the Joshua Bloch, the acknowledged expert on the subject, it is as authoritative as they come and extremely well-written. After six and a half years as a senior developer architecting and implementing algorithms and class libraries in Java, this book shocked me by summarizing much of what I knew about how to use the language effectively, while teaching me much that I did not know. It continues to top my recommended reading list for all new software developers at my company.
-dk
Effective Java is a book very much in the style of Scott Myers' earlier C++ "Effective" series
This is about the highest praise you can give a language-specific programming guide. In his books Scott not only listed many of the ways you could get in trouble in C++, but also gave clear explanations of why they were trouble and why his recommendations were good practices. His books are top of the list I recommend to people who know the language and want to write solid fast code. If Effective Java is as good, I'll soon be adding a copy to my bookshelf.
--Jim
Thank you, a good review of an excellent book. I have maybe 10 java books, most of them from O'Reilly and none have been as beneficial to my development in Java as this one.
The code and the text are both very clear and concise, and you can read the book cover to cover, coming back later to study each advice more in depth.
I think you can get it from reading between the lines in the review, but just to make it clear to any curious beginner, this is not the first book you should buy if you are just starting to learn java. Use
The Java Tutorial instead, and maybe
Learning Java.
Being bitter is drinking poison and hoping someone else will die
This is a fantastic book, and anybody's who's serious about writing good Java code should study it carefully. It's one of the best-written books -- may the best -- on the practical details of programming that I've ever encountered, and the advice is gold. The section on correctly implementing equals() and hashCode() alone is almost worth the price of the book.
The reviewer complains about some of the thinner or more "obvious" items, but I disagree. Heaven only knows how many times I've wished that really good and experienced programmers follow what seems the obvious maxim: "Minimise the accessibility of classes and members."
It's true that "Know and use the libraries" seems rather obvious and vague advice, but Bloch's exposition drives home the fact that you may not follow this advice as well as you think. As always, his examples are excellent: he shows how an innocuous-seeming abuse of java.util.Random creates serious problems, and how proper use of the libraries fixes the problem. How often do you write a loop to print the contents of an array? I never realized until Bloch pointed it out that System.out.println(Arrays.asList(array)) accomplishes the same thing much more simply.
If you're a Java programmer, get this book. If you're a technical author, aspire to it.
You could go with Delphi. Anecdotal evidence suggests that many VB programmers are switching to Delphi rather than to VB.Net.
Visually, there are lots of similarities with VB, but with more power. You can go under the hood and get as low-level as you want, short of device drivers (where at least a small part must be written in C/C++).
As a bonus, data-aware controls actually work! (even MS recommends not using them in production VB code.)
There is a version (C++ Builder) that uses C++ instead of Pascal as the basic language, and another package, Kylix, that can compile Delphi/C++B source code to run on Linux.
Borland also hosts a fantastic developer community (especially newsgroups), and most components, even commercial ones, have source available. Look at Torry's for thousands of components/tools/apps.
Many important Java techniques and idioms are described so well in this book that I have been known to insert comments to the effect of:
(or some such) into my code. Most of the author's items should be as engrained in the mind of a Java developer as terms like 'singleton' and 'event listener'.
Foreward - Preface - Acknolwedgements
1 Introduction
2 Creating and Destroying Objects
1: Consider providing static factory methods instead of constructors
2: Enforce the singleton property with a private constructor
3: Enforce noninstantiability with a private constructor
4: Avoid creating duplicate objects
5: Eliminate obsolete object references
6: Avoid finalizers
3 Methods Common to All Objects
7: Obey the general contract when overriding equals
8: Always override hashCode when you override equals
9: Always override toString
10: Override clone judiciously
11: Consider implementing Comparable
4 Classes and Interfaces
12: Minimize the accessibility of classes and members
13: Favor immutability
14: Favor composition over inheritance
15: Design and document for inheritance or else prohibit it
16: Prefer interfaces to abstract classes
17: Use interfaces only to define types
18: Favor static member classes over nonstatic
5 Substitutest for C Constructs
19: Replace structures with classes
20: Replace unions with chass hierarchies
21: Replace enum constructs with classes
22: Replace function pointers with classes and interfaces
6 Methods
23: Check parameters for validity
24: Make defensive copies when needed
25: Design method signatures carefully
26: Use overloading judiciously
27: Return zero-length arrays, not nulls
28: Write doc comments for all exposed API elements
7 General Programming
29: Minimize the scope of local variables
30: Know and use libraries
31: Avoid float and double if exact answers are required
32: Avoid strings where other types are more appropriate
33: Beware the performance of string concatenation
34: Refer to objects by their interfaces
35: Prefer interfaces to reflection
36: Use native methods judiciously
37: Optimize judiciously
38: Adhere to generally accepted naming conventions
8 Exceptions
39: Use exceptions only for exceptional conditions
40: Use checked exceptions for recoverable conditions and run-time exceptions for programming errors
41: Avoid unnecessary use of checked exceptions
42: Favor the use of standard exceptions
43: Throw exceptions appropriate to the abstraction
44: Document all exceptions thrown by each method
45: Include failure-capture information in detail messages
46: Strive for failure atomicity
47: Don't ignore exceptions
9 Threads
48: Synchronize access to shared mutable data
49: Avoid excessive synchronization
50: Never invoke wait outside a loop
51: Don't depend on the thread scheduler
52: Document thread safety
53: Avoid thread groups
10 Serialization
54: Implement Serializable judiciously
55: Consider using a custom serialized form
56: Write readObject methods defensively
57: Provide a readResolve method when necessary
References - Indexes of Patterns and Idioms - Index
Best of all, it's not 3 feet think like Effective Java Unleashed or The Effective Java Bible would be. You get lots of info with minimal fluff.
Washington, DC: It's like Hollywood for ugly people.
When this came out in 2001, James Gosling showed a copy of it at his keynote at JavaOne. They sold out every copy they had at the show, and the Effective Java talk later that day/week, was so packed you couldn't even get it. Great book.
I've been required to use Java non-stop from late 1995 until quite recently for school, internships, and then for my career. I've used every version of Java, and every API and just about every class available in the SDK. I've written applets, mathematical programs, games, medical database apps for the department of defense, class projects, enterprise-level call center applications, and just about anything else you could possibly conceive.
I've found in my experience that Java is good when it's highly specialized and kept very small and simple (yes, Java is good for APPLETS!). For enterprise applications, it _sucks_.
It's not that the language itself is bad (although it certainly has some gaping holes). It has more to do with the poor (buggy) implementation of the APIs and the real-time interpretation. Java isn't nearly as portable as they would have you believe (writing a 100-line applet and then running it on two different web browsers will tell you that.) Additionally, in my opinion, Java would have been much more useful if had been designed as a compiled (not interpreted) language.
In my current job, I use a lot more C++. I like it. It does what I tell it to do, and I don't have to second-guess the tools every time there's a problem.
...just my 2 gil.
Four sample chapters from the ten in the book are available in PDF format at the books website.
Ok, maybe you should view what I posted, and re-read the links.
IBM makes claims to Java at 90% speed of C++ in their numerical benchmarks. JavaGrande includes a number of well-respected organizations doing intensive computation, including GRID work. The tests quoted show a wide variety of performance, and you picked on file I/O; yes, one of the worst aspects in those tests. However, note that these are OLD JVM tests, not the significantly improved I/O found in JDK 1.4. (I don't have stats handy but have seen and experienced the claims of improved performance).
Java as an interpreted, cross-platform language will always be at a disadvantage to C++ in terms of raw speed. The again, many equate C++ as "Object Assembly" in the OOP world. That has it's own disadvantages.
Everything depends on how the language gets used. I have written many distributed C++ infrastructures and applications, and find Java a much welcome alternative. In many distributed scenarios it has proven faster, to the surprise of many seasoned collegues. I couldn't even imagine the jirations required to do an equivalent of JINI in C++.
So, why is it that most financial institutions have dropped C++ in favor of Java for server applications? It must suck something fierce, eh?
Don't learn Java. Learn OOP, and implement what you learn, as you learn, in Java. That is the best advice no one ever gave me. When you learn OOP, it doesn't matter what Java-like language you learn, as the real skill will be portable to other languages, like C#, SmallTalk, Python and Ruby. Let me explain.
I recently decided to go into the field of programming, and probably don't have 1/10th your development experience. However, my research skills are equal to anyone that I know, and they've certainly helped me in getting a grasp on the fundamentals of software engineering (or problem solving as I've learned to call it).
I chose Java because of its touted strengths, and because I wasn't sure of my target platform yet. I soon understood that as an introductory language, it has some conceptual hurdles that may get in the way when first learning to program. After a while, I began to understand the basics of programming by supplementing my self-study with older languages like BASIC. Essentially, diving straight into Java without first learning the standard structures of programming (sequence, selection, and repetition) was a handicap. However, for someone who already knows Visual Basic, such as yourself, the biggest hurdle will be the concepts of Object Oriented Programming.
If you think you "know" Object Oriented Programming but have only implemented it in VB, then I would suggest that you may not know everything that you need to program in OOP properly. There are plenty of Java programmers out there, but looking at some of their code, I see a definite lack of understanding in how to implement OOP. I see procedural programming techniques being applied to a language that will allow for it, but the developers lose the real advantages of using OOP.
I would recommend that you get a "beginners" book on Java (John Smiley is an excellent resource with his Learn To Program Java) to become familiar with the mechanics. If you prefer, you can try a Java in 21 Days/24 Hours type book. It doesn't matter, because if you follow my advice, you will actually learn to program OOP which is by far the largest hurdle, not syntax/grammar/classes. The most beneficial book I've found on the subject is from a master on the subject:
Sams Teach Yourself Object Oriented Programming in 21 Days
by Anthony Sintes
ISBN: 0672321092
This book will not only teach you how to program OOP, it will teach you to do it the right way. This is done by showing you how not to program OOP, and immediately showing you an alternative.
The author has some serious credentials: "Tony Sintes has worked with Object-Oriented Technologies since 1995. In that time, Tony has been part of many object-oriented development efforts. Currently, he works for BroadVision where his main responsibility as team mentor, building the skills of less-experienced developers. He brings his years of experience and ability to teach to different projects in order to guarantee their success.
Tony Sintes has written for JavaWorld, Dr. Dobb's Journal, LinuxWorld, JavaOne Today, and Silicon Prairie, where he produced a highly-regarded monthly column on Object-Oriented Programming. Tony currently writes JavaWorld's monthly Q&A column."
About the book: "Sams Teach Yourself Object Oriented Programming in 21 Days differs from other OOP books in two main ways. Many classic OOP books are designed for software engineers and teach at an academic level. Sams Teach Yourself Object Oriented Programming in 21 Days presents accessible, user-friendly lessons designed with the beginning programmer in mind. Other OOP books work to present both OOP and to teach a programming language (for example: Object-Oriented Programming in C++). Although Sams Teach Yourself Object Oriented Programming in 21 Days uses Java to present the examples, the book is designed to present concepts that apply to any OOP environment."
Days 1-7 cover the core OOP concepts with every other chapter covering the implementation of the concepts in the previous chapter and a boatload of do's and don'ts. For instance, in Chapter 2 you learn about Encapsulation theory (more importantly, what NOT to do). Chapter 3 you write code implementing Encapsulation...and so on.
Days 8-14 covers how to apply the OOP you've learned using design patterns like MVC.
Days 15-21 take the things you learned in the past 14 days, and make a GUI-based application. You apply the MVC pattern in making the app. Very cool.
...that Effective Java talks about by using a static code analyzer. Like this one:
http://pmd.sf.net/
PMD will find places where you've used concrete collections rather than interfaces, left unused code lying around, etc., etc.
Tom
The Army reading list
I know two Java books that are definitely worth their money:
- Effective Java
and
- Java Platform Performance by Steve Wilson and Jeff Kesselman
Of the second book there is a HTML version available at this link
Signature deleted by lameness filter.
If you're interested, you can get a free subscription to the print edition of Software Development Magazine. It's one of the few high quality freebees (and no, I am not affiliated with them). Also, as Scott Myers got mentioned here a few times: He writes for SD Magazine once in a while.
Under capitalism man exploits man. Under communism it's the other way around.