<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Java on Michael Hönnig</title><link>https://michael.hoennig.de/de/tags/Java/</link><description>Recent content in Java on Michael Hönnig</description><generator>Hugo -- gohugo.io</generator><language>de-DE</language><copyright>© 2026 Michael Hönnig</copyright><lastBuildDate>Wed, 08 May 2013 00:00:00 +0200</lastBuildDate><atom:link href="https://michael.hoennig.de/de/tags/Java/index.xml" rel="self" type="application/rss+xml"/><item><title>Tücken der Bean Validation (JSR#303) in JPA 2.0</title><link>https://michael.hoennig.de/de/blog/2013/2013-05-08-bean-validation-in-jpa2-0/</link><pubDate>Wed, 08 May 2013 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2013/2013-05-08-bean-validation-in-jpa2-0/</guid><description>Über einen kleinen aber wesentlichen Unterschied zwischen &lt;em&gt;Hibernate&lt;/em&gt; und &lt;em&gt;EclipseLink&lt;/em&gt; bei der Validierung neuer Entitäten.</description></item><item><title>4.-6. April: TDD Workshop und advanced TDD Seminar in Hamburg</title><link>https://michael.hoennig.de/de/blog/2011/2011-02-16-4-6-april-tdd-workshop-und-advanced-tdd-seminar-in-hamburg/</link><pubDate>Wed, 16 Feb 2011 00:00:00 +0100</pubDate><guid>https://michael.hoennig.de/de/blog/2011/2011-02-16-4-6-april-tdd-workshop-und-advanced-tdd-seminar-in-hamburg/</guid><description>Anfang April findet in Hamburg ein eintägiger Workshop zu TDD unter meiner Moderation und im Anschluss ein zweitägiges Seminar advanced TDD mit Johannes Link (u.a. Autor von &amp;ldquo;Softwaretests mit JUnit&amp;rdquo;) statt.</description></item><item><title>Mutationstests für JUnit-Tests</title><link>https://michael.hoennig.de/de/blog/2010/2010-05-23-mutationstests-fur-junit-tests/</link><pubDate>Sun, 23 May 2010 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2010/2010-05-23-mutationstests-fur-junit-tests/</guid><description>Unit-Tests sind in den meisten Java-Projekten schon selbstverständlich. Doch womit testet man eigentlich seine Unit-Tests? Die Code-Coverage alleine ist kein guter Maßstab, besagt diese doch noch nichts über die Wahrscheinlichkeit aus, mit der fehlerhafte Ergebnisse erkannt werden. Sollen doch sogar schon Unit-Tests ganz ohne Asserts geschrieben worden sein! Die Unzulänglichkeit von Unit-Tests kann mit so genannten Mutationstests aufgedeckt werden. Einige …</description></item><item><title>JSF: java.lang.IllegalArgumentException: "" at UIComponentBase.findComponent()</title><link>https://michael.hoennig.de/de/blog/2010/2010-04-27-jsf-java-lang-illegalargumentexception-at-uicomponentbase-findcomponent/</link><pubDate>Tue, 27 Apr 2010 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2010/2010-04-27-jsf-java-lang-illegalargumentexception-at-uicomponentbase-findcomponent/</guid><description>Nachdem ich einen XHTML Codeblock von einer Seite auf eine andere verschoben hatte, gab es plötzlich die folgende Exception in meiner JSF (MyFaces+Tomahawk+RichFaces) Anwendung:</description></item><item><title>mathematischer Funktions-Parser mit BeanShell</title><link>https://michael.hoennig.de/de/blog/2009/2009-11-17-mathematischer-funktions-parser-mit-beanshell/</link><pubDate>Tue, 17 Nov 2009 00:00:00 +0100</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-11-17-mathematischer-funktions-parser-mit-beanshell/</guid><description>Oft kommt man in Projekten in die Verlegenheit, Benutzer-definierte mathematische Funktionen zu berechnen, z.B. für einen Funktionsplotter. Solches lässt sich ohne große Umstände mit BeanShell erledigen:</description></item><item><title>Java Swing: Fensterhintergrund blinken</title><link>https://michael.hoennig.de/de/blog/2009/2009-11-11-java-swing-fensterhintergrund-blinken/</link><pubDate>Wed, 11 Nov 2009 00:00:00 +0100</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-11-11-java-swing-fensterhintergrund-blinken/</guid><description>Zur Visualisierung von Ereignissen, z.B. Warnungen - oder in meinem aktuellen Projekt zur Anzeige eines sich wiederholenden, zeitgesteuerten Ereignisses - kann man den Hintergrund von Java-Swing Fenstern ganz einfach kurz aufblinken lassen:</description></item><item><title>Buchempfehlung und -Rezension: Clean Code von Robert C. Martin</title><link>https://michael.hoennig.de/de/blog/2009/2009-09-03-buchempfehlung-und-rezension-clean-code-von-robert-c-martin/</link><pubDate>Thu, 03 Sep 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-09-03-buchempfehlung-und-rezension-clean-code-von-robert-c-martin/</guid><description>Meiner Meinung nach sollte das Buch Pflichtlektüre eines jeden Programmierers sein, gleich nachdem man Programmieren an sich gelernt hat! Aber auch für erfahrene Programmierer bietet das Buch eine gute Zusammenfassung vieler Prinzipien und Praktiken, teils als Erinnerung, teils als neue Einsichten. Sicherlich ist es nicht nur produktiver, sonst macht auch viel mehr Spaß, mit Kollegen zusammen zu arbeiten, die dieses …</description></item><item><title>Java in Echtzeitsystemen</title><link>https://michael.hoennig.de/de/blog/2009/2009-08-24-java-und-echtzeitsysteme/</link><pubDate>Mon, 24 Aug 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-08-24-java-und-echtzeitsysteme/</guid><description>Ein Echtzeitsystem garantiert, innerhalb einer definierten Zeit auf Signale oder Zustandswechsel zu reagieren. Ob diese Maximalzeit nun Mikrosekunden, Millisekunden, Sekunden oder gar Minuten sind, ist irrelevant. Doch kann man in Java-Programmen eine solche Maximalzeit garantieren?</description></item><item><title>Absoluter Nanosekunden-Zeitstempel in Java</title><link>https://michael.hoennig.de/de/blog/2009/2009-08-21-absoluter-nanosekunden-zeitstempel-in-java/</link><pubDate>Fri, 21 Aug 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-08-21-absoluter-nanosekunden-zeitstempel-in-java/</guid><description>Während meiner aktuellen Arbeit an einem Programm mit weichen Realtime-Bedingungen (soft real-time system) kam ich in die Verlegenheit, wissen zu müssen, wie viel Zeit zwischen dem Auftreten eines Interrupts in einem Linux-Kernel-Modul und seiner Verarbeitung im Java-Programm vergangen ist, weil das Ergebnis eines Zyklus, der über 200ms benötigte, verworfen werden müssen. Java bietet aber nur einen absoluten Zeitstempel in Millisekunden …</description></item><item><title>Maven: Versionsnummer aus pom.xml und Build-Zeitstempel mit Java auslesen</title><link>https://michael.hoennig.de/de/blog/2009/2009-08-12-maven-versionsnummer-aus-pom-xml-und-build-zeitstempel-mit-java-auslesen/</link><pubDate>Wed, 12 Aug 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-08-12-maven-versionsnummer-aus-pom-xml-und-build-zeitstempel-mit-java-auslesen/</guid><description>Bei Verwendung von Maven ist die Ziel-Versionsnummer des eigenen Programms in der pom.xml festgelegt. Selbstverständlich kann man auch aus dem Programm heraus mit Java darauf zugreifen, denn Maven erzeugt eine pom.properties Datei unterhalb von META-INF, in der u.a. die Versionsnummer und der Zeitstempel des Build steht:</description></item><item><title>Performance: Viele kurze Methoden vs. wenige lange Methoden</title><link>https://michael.hoennig.de/de/blog/2009/2009-08-11-performance-viele-kurze-methoden-vs-wenige-lange-methoden/</link><pubDate>Tue, 11 Aug 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-08-11-performance-viele-kurze-methoden-vs-wenige-lange-methoden/</guid><description>Viele Experten empfehlen, besser viele kurze Methoden zu programmieren als wenige lange Methoden. Dieselbe Regel kann auch aus anderen Empfehlungen abgeleitet werden. So führen z..B das Prinzip One level of abstraction und das Single Responsibility Principle zu kurzen Methoden. Und auch die Empfehlung, dass die im Quellcode verwendeten Bezeichner, also auch Methodennamen, ihr Subjekt ausreichend dokumentieren sollten, läuft auf kurze …</description></item><item><title>Einzel-Pin-Steuerung der parallelen Schnittstelle mit Java</title><link>https://michael.hoennig.de/de/blog/2009/2009-07-28-einzel-pin-steuerung-der-parallelen-schnittstelle-mit-java/</link><pubDate>Tue, 28 Jul 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-07-28-einzel-pin-steuerung-der-parallelen-schnittstelle-mit-java/</guid><description>Um es gleich vorweg zu sagen: Einzel-Pin-Steuerung in Java ist nicht sinnvoll möglich, da solche Funktionalität in einen Betriebssystem-Kernel gehört. Auf vielen modernen Betriebssystemen ist ein solcher Zugriff auch gar möglich bzw. spätestens das Interrupt-Handling dem Kernel vorbehalten. Der Lösungsweg soll daher auch genau auf diesem Wege erfolgen, also in Form eines Character-Device-Treibers für Linux 2.6.x. Dieser wird dann von …</description></item><item><title>Unit-Tests mit Mockito Mocks</title><link>https://michael.hoennig.de/de/blog/2009/2009-07-28-unit-tests-mit-mockito-mocks/</link><pubDate>Tue, 28 Jul 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-07-28-unit-tests-mit-mockito-mocks/</guid><description>In Unit-Tests werden immer wieder sogenannte Mock-Objekte benötigt, um zum vereinfachte Versionen der Objekte zu haben, mit dem der Test-Kandidat kommuniziert. Diese müssen aber zum einen sinnvoll auf Methoden-Aufrufe reagieren, so dass der Test-Kandidat überhaupt funktionieren kann. Und zum anderen muss teilweise geprüft werden, ob der Test-Kandidat an diesen Objekten bestimmte Methoden mit bestimmten Parametern gerufen hat.</description></item><item><title>Wenn Jemmy bei clickMouse() in invokeAndWait() hängt</title><link>https://michael.hoennig.de/de/blog/2009/2009-07-28-wenn-jemmy-bei-clickmouse-in-invokeandwait-hangt/</link><pubDate>Tue, 28 Jul 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-07-28-wenn-jemmy-bei-clickmouse-in-invokeandwait-hangt/</guid><description>Jemmy ist ein hervorragendes Werkzeug zur Unterstützung von Unit-Tests von Swing-basierten-Anwendungen. Doch durch einen neuen Test, hing ein zuvor durchlaufender Testfall plötzlich tief unter JButtonOperator.clickMouse(), genau genommen in Queue.invokeAndWait().</description></item><item><title>Aktuellen Stack-Frame ermitteln</title><link>https://michael.hoennig.de/de/blog/2009/2009-07-22-aktuellen-stack-frame-ermitteln/</link><pubDate>Wed, 22 Jul 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-07-22-aktuellen-stack-frame-ermitteln/</guid><description>Der aktuelle Stacktrace kann in Java ganz einfach mit Thread.currentThread().getStackTrace(); ermittelt werden. Doch darin enthalten ist dann auch die Methode getStackTrace() selbst.</description></item><item><title>UNIX Tools (grep, diff etc.) in Java</title><link>https://michael.hoennig.de/de/blog/2009/2009-07-22-unix-tools-grep-diff-etc-in-java/</link><pubDate>Wed, 22 Jul 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-07-22-unix-tools-grep-diff-etc-in-java/</guid><description>Wer Perl- und bash-Scripte nach Java umschreiben soll, hat sich sicherlich dabei eine in Java implementierte Sammlung von UNIX-Tools wie grep, diff etc. gewünscht. Fündig wird man unter &lt;a href="https://www.java2s.com" target="_blank" rel="noreferrer"&gt;www.java2s.com&lt;/a&gt;.</description></item><item><title>Magisches Programmende beim Debuggen von Java Threads mit Eclipse</title><link>https://michael.hoennig.de/de/blog/2009/2009-07-21-magisches-programmende-beim-debuggen-von-java-threads-mit-eclipse/</link><pubDate>Tue, 21 Jul 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-07-21-magisches-programmende-beim-debuggen-von-java-threads-mit-eclipse/</guid><description>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.</description></item><item><title>Code-Coverage von JUnit Tests mit Eclipse und Maven</title><link>https://michael.hoennig.de/de/blog/2009/2009-07-15-code-coverage-von-junit-tests-mit-eclipse-und-maven/</link><pubDate>Wed, 15 Jul 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-07-15-code-coverage-von-junit-tests-mit-eclipse-und-maven/</guid><description>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.</description></item><item><title>ursprüngliche Ursache von Exceptions</title><link>https://michael.hoennig.de/de/blog/2009/2009-06-18-ursprungliche-ursache-von-exceptions/</link><pubDate>Thu, 18 Jun 2009 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2009/2009-06-18-ursprungliche-ursache-von-exceptions/</guid><description>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&amp;rsquo;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 &amp;hellip; gibt schon …</description></item><item><title>JSF Controller ohne getter/setter</title><link>https://michael.hoennig.de/de/blog/2008/2008-08-07-jsf-controller-ohne-gettersetter/</link><pubDate>Thu, 07 Aug 2008 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2008/2008-08-07-jsf-controller-ohne-gettersetter/</guid><description>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.</description></item><item><title>generierte Webservice-Klassen im Client Serializable machen</title><link>https://michael.hoennig.de/de/blog/2008/2008-07-16-generierte-webservice-klassen-im-client-serializable-machen/</link><pubDate>Wed, 16 Jul 2008 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2008/2008-07-16-generierte-webservice-klassen-im-client-serializable-machen/</guid><description>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:</description></item><item><title>Resource-Bundles automatisch von UTF-8 nach Quoted-ASCII konvertieren</title><link>https://michael.hoennig.de/de/blog/2008/2008-07-02-resource-bundles-automatisch-von-utf-8-nach-quoted-ascii-konvertieren/</link><pubDate>Wed, 02 Jul 2008 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2008/2008-07-02-resource-bundles-automatisch-von-utf-8-nach-quoted-ascii-konvertieren/</guid><description>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.</description></item><item><title>JSF mit Spring Webflow: Buttons ohne Funktion</title><link>https://michael.hoennig.de/de/blog/2008/2008-06-28-jsf-mit-spring-webflow-buttons-ohne-funktion/</link><pubDate>Sat, 28 Jun 2008 00:00:00 +0200</pubDate><guid>https://michael.hoennig.de/de/blog/2008/2008-06-28-jsf-mit-spring-webflow-buttons-ohne-funktion/</guid><description>Vor einigen Tagen bemerkte ich in einer neuen Applikation mit JSF und Spring Webflow, dass die Umlaute in den Formularen falsch übertragen wurden. Bei reinen JSF-Applikationen hatte ich dahingegen mit der Kodierung noch nie Probleme.</description></item></channel></rss>