Forgot your password?
typodupeerror
Programming Books Media Book Reviews IT Technology

Effective Java 157

Posted by timothy
from the strong-coffee dept.
benjiboo writes "From the back page: 'Are you looking for a concise book packed with insight and wisdom not found elsewhere? Do you want to gain a deeper understanding of the Java programming language? Do you want to write code that is clear, correct and reusable?' I did, so I bought the book and decided to use it for my first review :)" Read on for bejiboo's review of Effective Java.
Effective Java Programming Language Guide
author Joshua Bloch
pages 252
publisher Addison Wesley
rating 8/10
reviewer Ben
ISBN 0201310058
summary 57 pieces of Java wisdom.

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.

This discussion has been archived. No new comments can be posted.

Effective Java

Comments Filter:
  • thanks benjiboo (Score:1, Interesting)

    by nuffle (540687)
    thanks for submitting a rare thing: a good slashdot book review. timothy, if you want us to pay any attention to these reviews, you need to keep the quality more like this one.
  • by burgburgburg (574866) <splisken06@emai3.14l.com minus pi> on Wednesday January 15, 2003 @12:41PM (#5088405)
    How can it possibly be effective if it isn't .Net? I mean, if it exists outside of Microsoft then how can it do anything? Listen. They're calling us to Carousel. Perhaps our code will be renewed.

    Do not talk of this Java Sanctuary. There is no such thing.

    • What? Did I forget to include emoticons or <sarcasm></sarcasm> tags? Did I not make the references to "Logan's Run" explicit enough? Sheesh. Flamebait.
    • Haven't you heard? Our revered leaders, the beloved Bill and Ted^H^H^HSteve, have been instructed by the Leaders of the High Command, George and Dick, to include this "Java" in every shiny new copy of the .NET mother ship, which we fondly know as Windows. So bow down to the great and mighty Java, we must worship it now, for it has been ordained...

      [Sorry I couldn't keep your Logan's thing going...]

  • It's just not a review without the Table of Contents [slashdot.org]! :)
    • Ask and ye shall receive. [sun.com]

      I tried to post it. I really did. The slashdot filters just wouldn't let me. Seems like 37 characters per line should be plenty. Whatever.

    • by Anonymous Coward
      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
  • The author (Score:5, Informative)

    by dubbayu_d_40 (622643) on Wednesday January 15, 2003 @12:47PM (#5088436)
    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...
  • Java Rules (Score:3, Funny)

    by HealYourChurchWebSit (615198) on Wednesday January 15, 2003 @12:49PM (#5088458) Homepage


    Man, I'm barely done with Douglas Dunn's [amazon.com]
    Java Rules and now I gotta read this?

    Actually, I'm glad to see more book son coding effectively as opposed to the dummy approach which is a sure way to Shoot yourself in the foot [healyourch...ebsite.com] when the maintenance phase rolls around.

    That said, one thing copiously missing from the review is whether or not the book covers J2EE at all -- which by and far requires some guidance in the developing the most effective Java applications.

    • Then you want Java Enterprise Best Practises [amazon.co.uk]
    • I have the book, it doesn't cover J2EE at all.

      To be fair, that would be outside the scope of the book. It covers Java itself, the core language as an O'Reilly book might call it. I find it to be quite handy and well-written and agree with the reviewer for the most part.

      I may check out Java Rules now. To easy to make fun of that name: Hey dude, Java Rules!

    • Try "Java Enterprise Best Practices", (c)2003 - O'Reilly.
      Chapters
      • 1 - Introduction to Java Enterprise Best Practices (b.p)
      • 2 - EJB b.p
      • 3 - Servlet b.p.
      • 4 - JDBC b.p
      • 5 - XML b.p
      • 6 - RMI b.p
      • 7 - Java Management Extensions
      • 8 - Enterprise Internationalization
      • 9 - JSP b.p
      • 10 - JavaMail b.p.
      • 11 - Enterprise Performance Tuning

      The authors include Hans Bergsten, William Crawford, Dave Czarnecki, Andy Deitsch, Robert Eckstein, William Grosso, Jason Hunter, Brett McLaughlin, Sasha, Nikolic, J. Steven Perry, George Reese, and Jack Shirazi.

      This not a bad book. For $34(USD), there are some good learnings. This is one to have on the shelf.
  • ... is the Java 2 Performance and Idiom Guide (ISBN:0130142603), by Craig Larman and Rhett Guthrie.
  • by dknj (441802) on Wednesday January 15, 2003 @01:17PM (#5088616) Journal
    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
    • by goul (41924) on Wednesday January 15, 2003 @02:06PM (#5088848)
      Indeed. It might be worth noting that James Gosling (one of the parents of Java) describes this as a book he needs.
      This book will show you any bad habits that you have picked up, and teach you why they are bad. I've not found a single developer of any level of experience who has not found this book useful.
      • Here's the Gosling quote from the back cover, which I get a big kick out of every time:

        I sure wish I had had this book ten years ago. Some might think that I don't need any Java books, but I need this one." -James Gosling, Fellow and Vice President, Sun Microsystems, Inc.

        Easily one of the top five Java books ever, along with Thinking in Java (2nd. ed., Eckel) and Concurrent Programming in Java (2nd. ed., Lea)

    • Agreed; I found it useful as a Java newbie, because it gave me a view of the language "from the other side", a sense of where its complexities lay. It is a fine example of how to think about design issues in the context of a set of linguistic constraints, and for this reason has something of value even for non-Java coders (as the Scott Meyers series has much of value for non-C++ coders).

  • by Hirofyre (612929) on Wednesday January 15, 2003 @01:34PM (#5088681)
    There are a lot of Java books out there, but this is one that will help an intermediate-to-advanced Java developer. The code examples in here are concise, clean, and hard-hitting. The layout of the book allows you to pick it up and learn something if you have 10 minutes or 2 hours.
    When I was first learning Java, I often had that nagging feeling that I was making things harder on myself than need be. This book cleared up a lot of those feelings, and helped get me on the right track for some of the great tools hidden away in the Java API. The API documentation is great for showing you what members and functions are available to an engineer, but this book shows you how to use the API. The review cites the author's avocation of knowing the libraries, I would contend that this book would help you get the most out of those libraries, and increase your understanding of them.
    This book has become a must-have around my office, and if you are looking to get over-the-hump and move from an intermediate to advanced java software engineer, pick up this book. It is dense with information, and will save you a ton of time and energy. What more could you ask for from a book?
    • There is something about the idea of code examples being "hard-hitting" that made me laugh out loud.
  • Scott Myers (Score:5, Informative)

    by kzinti (9651) on Wednesday January 15, 2003 @01:45PM (#5088724) Homepage Journal
    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
    • Re:Scott Myers (Score:5, Informative)

      by MSBob (307239) on Wednesday January 15, 2003 @03:14PM (#5089291)
      It's not as good. I own this book and own both C++ books by Scott Meyers and this one is not nearly the level of Meyers' titles.

      The topics it discusses are much more obvious than the traps that Meyers covered. Java's a simpler language, that's fair enough but there are areas of Java, especially around concurrent programming and network and io apis that may surprise even experienced developers. Those areas are precisely where 'Effective Java' is thin on content and I found it disappointing overall.

      Just because it's sectioned the same way as Scott Meyers' books doesn't mean it's just as good!

      • Ah, it actually feels good to read someone who disagrees after the overwhelming praise of the book here on Slashdot (and I was one of the hallelulia choir), especially as its from someone who sounds like he is not just a Java hater.

        there are areas of Java, especially around concurrent programming and network and io apis that may surprise even experienced developers.

        Do you have any suggestion for a book or online resource where I could learn more about these things?

        I mean, yes, I know a little about those areas, and I know where to find books that teach them, but since you seem to have a lot of experience (I mean it, no sarcasm), do you have any tips for a source that cover these important areas you say Boch neglects, just as well as he does the rest?
        • Re:Scott Myers (Score:2, Informative)

          by pamar (538061)
          Do you have any suggestion for a book or online resource where I could learn more about these things?


          Regarding concurrent programming, I would go for "Taming Java Threads" by Allen Holub.

          A lot people would also cite "Concurrent Programming in Java: Design Principles and Pattern" by Doug Lea.

          Personally I prefer the first. The second one is far more complete in its exhaustive analysis of concurrent programming, but the first is more "hands-on".
  • by sdcharle (631718) on Wednesday January 15, 2003 @01:45PM (#5088735) Journal
    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.

    What does 'setting out his stall' mean? I picture somebody settling on to the toilet and opening the newspaper, but in the context I don't think that's what you meant.

  • Good review (Score:4, Informative)

    by LarsWestergren (9033) on Wednesday January 15, 2003 @01:47PM (#5088743) Homepage Journal
    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 [sun.com]
    The Java Tutorial instead, and maybe [oreilly.com]
    Learning Java.
  • by melquiades (314628) on Wednesday January 15, 2003 @01:49PM (#5088751) Homepage
    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.
  • A "Must Have" (Score:3, Informative)

    by Atom Tan (147797) on Wednesday January 15, 2003 @01:51PM (#5088763) Homepage
    In my opinion, this book is a "must have" for anyone that wants to develop Java code at anything more than a casual level.

    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:


    // Hash code implementation per "Effective Java" Item 9


    (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'.
  • by SecretAsianMan (45389) on Wednesday January 15, 2003 @02:14PM (#5088905) Homepage
    ...of this book, and I will most definitely finish it when I have the time. Unless you are a balls-to-the-wall guru already (99.999% chance you aren't), you will become a better Java developer by reading this book. It pays to read even some of the simpler and more obvious tips, as your viewpoint on those issues might not be as omniscient as you think.

    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.

    • Read this book a lot (Score:3, Interesting)

      by mobiGeek (201274)
      This is not a read-once-keep-on-bookshelf book. This book should be read through a few times at least.

      I rarely find a tech book that offers more than a few examples I ear-mark. This book however has me re-reading it from time to time. The lessons picked up take time to sink in, and IMO no one can truly pick up all of the lessons on one read through.

  • This book is great (Score:4, Informative)

    by deanj (519759) on Wednesday January 15, 2003 @02:39PM (#5089074)
    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 got into that session. Not only did Bloch write a great book, the session was *awesome*. Sure, the cynical could see it purely as advertising for the book (he covered 4 or 5 of the items), but he was an extremely compelling speaker.
    • 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.

      While I appreciate your comment, I want to humbly submit that, this being slashdot, you might have used a subject line more in line with the way the editors pick headlines. For example, instead of the mundane-but-descriptive subject "This book is great", you should have used something like:

      "Dangerous book leads to shortages and overcrowding" :)
  • Decent review of an excellent book.

    I read books like other people eat hot dinners, and when I recommend Java books in work I only recommend this one. (I tend to find that a surprisingly number of coders only read one or two tech books a year anyway). "Effective java" is very well written; it's nice and short without sacrificing any exposition of the hairer parts of the language.

    And as another poster has said, at work it's often sufficient to say in a review, "HashCode as per Bloch please"
  • I have this book and have read it. As an experienced java developer I found that this book had a few really good insights, and a whole load of good reminders. I'd say that it's a good review for the real pros and an indispensible piece of training for beginners and intermediate level programmers. That's much more than can be said for most books. I agree with the reviewer regarding the examples and the readability.

    It's nice to see a book review that actually reviews the book, rather than just regurgitating the table of contents.

  • Sample Chapters (Score:5, Informative)

    by darkpurpleblob (180550) on Wednesday January 15, 2003 @03:12PM (#5089278)
    Four sample chapters from the ten in the book are available in PDF format at the books website [sun.com].
  • 'Minimise the accessibility of classes and embers,'

    ...Because otherwise you might get burned.

    So sorry. My weird sense of humour strikes again.

  • by tcopeland (32225) <tom.thomasleecopeland@com> on Wednesday January 15, 2003 @04:28PM (#5089797) Homepage
    ...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
  • I bought this book some time ago. It really helped me. Each section is concise and incredibly well written. Buy it.

  • In two words, dynamic compilation and inlining. You can do a lot more with dynamic information and dynamic performance profile. Being able to inline 50-100 nested calls in a hot spot may give you something the most sophisticated static compiler will never dream of.
    (F.e. you can eliminate a virtual method call just because you dynamically know what method you are actually calling; you can inline methods from system and third party classes, etc.). Just don't forget to add -server to your java run.
  • Worth the money (Score:2, Informative)

    by grungeman (590547)
    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 [sun.com]


  • I bought the book last June because it got the 2002 Jolt award for Books [sdmagazine.com]. I rarely got disappointed by Jolt award winners (books and otherwise), and this book is no exception - it rocks!

    If you're interested, you can get a free [sdmagazine.com] 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.

  • This is the best java book I have read. I swear I already knew 80% of what is in the book but I had forgotten half.

    But the most useful thing about the book is that you can quote it to people. It has been a useful tool for applying to the Open Source mailing list I have to participate in.

    And if you are writing an API in Java you need this book shipped to you overnight delivery. You can thank me later.
  • by pb (1020) on Wednesday January 15, 2003 @07:37PM (#5090977)
    I'm not a big fan of Java, but I was impressed by everything that has been said here about how much Java has matured, so I figured I'd put it to the test.

    I dug up some old benchmarks (the BYTEmarks, which includes a jBYTEmark, normalized to that same P90) that I can use to fairly compare Java and C performance.

    I've got a 1.2Ghz Duron, and the C version of the BYTEmarks seems to reflect this accurately--with scores of 26.6 Integer and 21.4 FP, with a P90 being 1.00.

    I'm comparing this against two separate Java implementations--Sun's JVM for Linux, and gcj (I also tried out a program that translates Java bytecodes to C, but the resultant executable didn't perform correctly). Here's a table of results:

    C Bytemark: INT: 26.6 FP: 21.4
    SUN (--server) INT: 4.21 FP: 1.80
    GCJ INT: 3.63 FP: 1.71
    SUN (Default) INT: 2.18 FP: 2.14

    Now, I'm not surprised that the C version ran so fast, but I am surprised the the Java benchmarks did so badly, considering that both benchmarks were normalized to an index of 1.0 for the same Pentium 90! Maybe I got a bad copy of the jBytemarks--it was hard to find a copy at all--but it looks pretty legit.

    Do any of you Java people have some amazing tips for me? I did use all the optimization flags I could find. Or is this typical performance for Java, making a 1.2Ghz Duron run as slow as a P200 or a K6/300?
    • by pb (1020)
      After doing a bit more research about JVMs, I installed IBM's JVM, which outperforms both GCJ and Sun here:

      IBM INT: 5.8 FP: 6.4

      These results still aren't as good as I'd hoped, but it does show that all of the JVMs aren't up to par yet, and therefore should be careful in choosing one!
    • I don't think i understand what you're doing here; it sounds like you're using totally different benchmarks in C and java, so the numbers shouldn't be comparable at all, should they?

      At best you might be able to compare jvms with it, but since the benchmark is designed to measure cpu performance (isn't it?) it might not give meaningful results for that either.

      --
      Benjamin Coates
      • The BYTEmarks are CPU performance tests, designed to measure the performance of a new CPU or platform. Both the C and the Java tests were run on the same P90 (an INT and FP score of 1.00 = P90 performance) and can therefore be compared to that.

        You're right about the JVM performance issue--I think it was originally normalized with Symantec's Visual Cafe? I can only assume they tried to use the best Java implementation they could at the time, but judging from straight CPU performance, I can only infer that JVMs have gotten worse, or that there are other factors at work. Maybe I should try those JVMs under Windows to see how drastic the performance difference is.
    • try ibm:s jdk. it is 20 % faster than gcc-c-code on FIR-filter (float-perofrmance).
    • Do any of you Java people have some amazing tips for me? I did use all the optimization flags I could find. Or is this typical performance for Java, making a 1.2Ghz Duron run as slow as a P200 or a K6/300?

      Sure. Wipe the words milliseconds, GHz, performance, benchmark, and optimization from you memory. They don't matter in about 99.99% of all programming, and caring about them where you shouldn't is likely to lower the quality of your program code. In particular they don't matter when comparing languages. Thank you for your consideration.

      • I happen to enjoy benchmarking; it's a good way to compare different languages and language implementations, and also a good way of testing how much a particular language implementation (or set of them) has matured over time.

        Obviously the times to care about benchmarking are 1) before you start coding -- if performance is important, find a good set of tools for your project and 2) when you're done with a cycle of development, to test the performance of your application, and see how it can be improved.

        So far, I've found that C implementations haven't (or can't?) improve too much more (i.e., an order of magnitude) while Java implementations easily can (and, in fact, can easily show orders of magnitude performance differences).

        But most of the time, your tips are applicable, much like the first rule of optimization.
        • I'm coming pretty late to this discussion, but you still might see this. It sounds as though you're asking a sincere question, and I think you deserve a better answer.

          I don't know how you did your tests, but Java benchmarking is a funny thing. Java should be run in a HotSpot or equivalent runtime optimizer, and when it is you get a slow startup time, slow runs for the first few runs of an app, and then quite fast performance thereafter after the code has been compiled, optimized, and cached by the runtime system.

          On a server, that's how a real Java app operates. It is started up, then it is run again and again within an ongoing process. It doesn't have to restart and recompile, so it spends most of its time running quite fast after a slow start. Benchmarks that look at the first run instead of the 1000th are okay for C but completely misrepresent Java. Measurements should reflect the 99.9% case, not the exceptional case (startup).

          In my own informal experiments, I've found that Java gets pretty close to C++ after it gets rolling. (I haven't benchmarked against C.) The differences are interesting to me, too, but are usually swamped by other issues such as database connections that dwarf the language delta.

  • ...until my employer made me work with Java visionary and author Patrick Naughton [slashdot.org]. Now I don't want anything to do with it.
  • I am an infrequent Java programmer, but I found this book extremely useful when thinking about design in other languages. Much of the advice about how to fashion reusable libraries, how to think of the users of your class as potential wrong-doers is extremely useful.
  • This is a great book for those who know some about Java, and want to know more.

    Also, if you ever get a chance to see Joshua speak, go for it! He's a really engaging speaker, much better than the rest of us nerds :-)

We can predict everything, except the future.

Working...