Gerade traf mich beim Debuggen ein seltsames Verhalten meines Java-Programms unter Eclipse. Die Anwendung ist multithreaded und der wichtigste Thread wurde trotz Breakpoint auf erster Zeile in der run()-Methode oft gar nicht erst betreten, bzw. die Anwendung terminierte während Eclipse auf dieser Zeile angehalten hatte. Kein System.exit() meiner Anwendung wurde dabei durchlaufen.
Meistens benutze ich für die Messung der Code-Coverage von Tests EclEMMA, da dieses als Eclipse-Plugin die Code-Coverage direkt in Eclipse anzeigt.
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 …
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: