Java

Der aktuelle Stacktrace kann in Java ganz einfach mit Thread.currentThread().getStackTrace(); ermittelt werden. Doch darin enthalten ist dann auch die Methode getStackTrace() selbst.

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.