Blog

Fast täglich, meist beim Debuggen, aber auch für Logfiles, muss ein Java-Entwickler die ursprüngliche Ursache einer Exception herausfinden. So nützt einem die Meldung Can’t commit because the transaction is in aborted state, die ein Applikationsserver z.B. nach der Verletzung eines Datenbank-Constraints liefern würde, recht wenig, doch das tief darin verborgene SQLSTATE[23505] ERROR: duplicate key violates unique constraint … gibt schon …

Wie Spiegel.de berichtet, sank die Inflationsrate im Mai 2009 auf 0%. D.h. zum einen, im Schnitt bleiben die Preise stabil. Doch was die wenigsten bedenken, bedeutet es auch, dass der Realzinssatz auf Geldbasis (Bargeld und Guthaben bei der EZB) damit ebenfalls 0% beträgt - und das wiederum hat unangenehme Auswirkungen.

Die JavaBeans Spezifikation erlaubt public Member-Variable direkt als Properties zu verwenden, oder eben alternativ public getter/setter Methoden. Die JSF EL (JavaServer Faces Expression Language) aber akzeptiert ausschließlich getter/setter Methoden. Getter/setter Methoden werden jedoch zunehmend als Anti-Pattern gesehen, eine Diskussion hierzu findet sich im Blog von Adam Bien.

Mein laufendes Projekt ist ein Client für vorgegebene Webservices. Aus der WSDL-Datei werden durch eine Konfiguration in der pom.xml über das wsimport Kommando des Maven2-Plugins org.codehaus.mojo:jaxws-maven-plugin mit xjc Java-Klassen generiert. Nun ergab sich die Notwendigkeit, diese Klassen Serializable zu machen. Nach einer kurzen Recherche kam ich auf die folgende Lösung:

Java Resource-Bundles (i.d.R. .properties) müssen in ISO-8859-1 bzw. Quoted-ASCII erstellt sein. XML- und Java-Dateien dahin gegen hält man heute meist in UTF-8. In einem Projekt, in dem jeder Entwickler mit einer grafischen Entwicklungsumgebung arbeitet, die man so konfigurieren kann, dass jeweils der richtige Zeichensatz verwendet wird, ist das kein Problem.