"Writing Better (Java) Code: A Conversation with Brian Goetz

In dem Interview mit dem unhandlichen Titel "Writing Better Code: A Converstion With Sun Microsystems Technology Evangelist Brian Goetz" im Sun Developer Network verbringt sich ein sehr interessanter Artikel über Javaprogrammierung und insbesondere zur Fragen der Performance.

Insbesondere will Goetz, der Hauptautor von "Java Concurrency in Practice"(amazon.de,ub.upb.de), mit einigen Performancemythen aufräumen.
So stellt er der Befürchung, threadsichere-Programmierung sei nur mit einem Verlust an Performance möglich, entgegen, dies sei vor 10 Jahren wahr gewesen aber heute nicht mehr:

Every major JDK release has reduced the overhead of synchronization over the previous version. Yes, there’s still overhead, but people worry too much about that and not enough about writing clean, correct code.

Interessant ist auch die Antwort auf die Frage wie Entwickler am besten schnellen Javacode schreiben:

The answer may seem counterintuitive. Often, the way to write fast code in Java applications is to write dumb code — code that is straightforward, clean, and follows the most obvious object-oriented principles. This has to do with the nature of dynamic compilers, which are big pattern-matching engines. Because compilers are written by humans who have schedules and time budgets, the compiler developers focus their efforts on the most common code patterns, because that’s where they get the most leverage. So if you write code using straightforward object-oriented principles, you’ll get better compiler optimization than if you write gnarly, hacked-up, bit-banging code that looks really clever but that the compiler can’t optimize effectively.
[...]
My advice is this: Write simple straightforward code and then, if the performance is still not "good enough", optimize. But implicit in the concept of "good enough" is that you need to have clear performance metrics. Without them, you’ll never know when you’re done optimizing. You’ll also need a realistic, repeatable, testing program in place to determine if you’re meeting your metrics. Once you can test the performance of your program under actual operating conditions, then it’s OK to start tweaking, because you’ll know if your tweaks are helping or not. But assuming "Oh, gee, I think if I change this, it will go faster" is usually counterproductive in Java programming.