Deutsches Java Blog von Jörg Herbst

Als Java Programmierer der ersten Stunde hat man bestimmte Dinge schon früh gelernt. Zum Beispiel der Vorteil eines StringBuffer. Von daher war mir auch ziemlich schnell klar wie folgende Frage zu beantworten war:

Welche Methode ist schneller?

a)

String a = "Das" + " " + "ist" + "das" + " " + "Haus" + " " + "des" + " " + "Nikolaus";

b)

StringBuffer b = new StringBuffer().append("Das").append(" ").append("ist")
.append("das").append(" ").append("Haus")
.append(" ").append("des").append(" ")
.append("Nikolaus");


Klar Methode b) ist schneller. Zwar lässt sich Code mit einem StringBuffer etwas scherer lesen, aber es werden nicht laufend neue String Objekte erzeugt

Klingt einleuchtend ist aber vollkommener Blödsinn. String Verkettungen mit dem ‘+’ Operator wandelt der Java Compiler seit Java 1.1 bis 1.4 automatisch in StringBuffer Objekte um. Sprich der code a) und b) ergiebt identischen Bytecode. Ab Java 5 dreht sich die ganze Sachen dann sogar um, hier hat Sun die Klasse StringBuilder eingeführt. Diese ist um einiges schneller als der alte StringBuffer, was dazu führt das a) deutlich schneller ist als b).

Nachdem ich seit einiger Zeit regelmäßig meinen Quellcode mit Findbugs überprüfen lasse, ist mir dabei der ein oder andere Fehler schon aufgefallen. Seht stutzig wurde ich allerdings als ich die Fehlermeldung bekam, dass die statische Verwendung von SimpleDateFormat nicht Thread safe sei.
Bisher hatte ich ziemlich oft stellen wie

private static final DateFormat DEFAULT_DATE_FORMAT = new SimpleDateFormat("dd.MM.yyyy");

in meinem Code und es war mir erst mal nicht klar was daran falsch sein sollte.

Einige Rechersche haben mich auf diesen Artikel von Daniel Schnell gestoßen, wo er sehr ausführlich schreibt, warum dieser Code nicht Thread Safe ist, und somit zu unerwartetem Verhalten bis hin zu ArrayIndexOutOfBoundsException (!) führen kann. Da ich aber auf mein statisches DateFormat nicht verzichten wollte habe ich mich auf die Suche nach einer Alternative gemacht und bin bei Apache fündig geworden.
Die commons-lang Bibliothek enthält eine Klasse FastDateFormat die explizit Thread Safe ist und damit mein Problem löst. Als kleines Bombon soll die Klasse auch noch ein wenig schneller als die Sun Implementierung sein. In meinem Code werde ich wo möglich demnächst also die Apache Alterantive der Sun Variante vorziehen.