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.
Kleine Offtopic-Frage:
Warum ein statisches, nicht finales und privates Attribut, und kein Objektattribut? Hat das bei dir irgendwelche Designhintergründe? Normalerweise sollte static ja soweit möglich vermieden werden.
Gruß
Stefan
Völlig korrekt, entweder man arbeitet mit einer Konstante (mit allen daraus resultierenden Konsequenzen) oder wirklich mit einer Klassenvariable.
Im konkreten Fall benötige ich sehr viele Instanzen von den Objekt und möchte nicht für jedes Objekt eine neue DateFormat Instanz erzeugen müssen, von daher habe ich mich hier für static entschieden, das final habe ich ergänzt.