Arno Haase

Arno Haase
Arno Haase ist freiberuflicher Softwareentwickler. Er programmiert Java aus Leidenschaft, arbeitet aber auch als Architekt, Coach und Berater. Seine Schwerpunkte sind modellgetriebene Softwareentwicklung, Persistenzlösungen mit oder ohne relationaler Datenbank und nebenläufige und verteilte Systeme. Arno spricht regelmäßig auf Konferenzen und ist Autor von Fachartikeln und Büchern. Er lebt mit seiner Frau und seinen drei Kindern in Braunschweig.
Beiträge dieses Autors

Aus der Java-Trickkiste: Java-Serialisierung – wann passt sie, wann nicht?

Serialisierung ist ein Mechanismus, bei dem Objekte in eine Folge von Bytes verwandelt und umgekehrt daraus wieder Objekte erzeugt werden. Man braucht solche Mechanismen beispielsweise für das Aufrufen über ein Netzwerk oder um Objekte in einer Datenbank zu speichern. Java bringt dafür von Haus aus einen Mechanismus mit: die Serialisierung im engeren Sinne. Die ist trotz ihrer Schwächen so weit verbreitet, dass wir sie heute näher betrachten.

Aus der Java-Trickkiste: Code ohne Seiteneffekte

Funktionale Programmierung im üblichen Sinne hat zwei zentrale Merkmale: Funktionen und Seiteneffektfreiheit. Funktionen unterstützt Java seit der Einführung von Lambdas, aber das Programmieren ohne Seiteneffekte hat irgendwie den Sprung in die Java-Kultur noch nicht so recht geschafft. Der Artikel stellt dieses Paradigma vor und macht – hoffentlich – Lust darauf.

Aus der Java-Trickkiste: Microbenchmarking

Performancemessungen sind notorisch schwierig. Je kürzer ein Stück Code läuft, desto schwieriger wird es, sinnvolle Werte zu ermitteln. Und wenn es um einige wenige Statements geht, überdecken die Effekte des Messens leicht das Verhalten des zu messenden Codes.

Java-Trickkiste: Der JIT-Compiler von Hotspot

Die Hotspot-JVM liest Class-Dateien ein und führt das entsprechende Java-Programm aus. An irgendeiner Stelle „kompiliert“ sie das Programm noch einmal und wendet dabei ausgefeilte Verfahren an, sodass Java-Programme bemerkenswert schnell laufen. Das ist in etwa das, was man beim Entwickeln von Geschäftsanwendungen über den JIT-Compiler wissen muss. Wenn man aber z. B. performancekritischen Code schreibt oder einfach nur neugierig ist, lohnt sich ein Blick hinter die Kulissen.

Aus der Java-Trickkiste: Hotspot-Schalter

Die meisten Java-Entwickler wissen, wie man bei einer JVM die maximale Heap-Größe setzt oder – zumindest vor Java 8 – den Speicher für die Permanent Generation vergrößert. Aber Hotspot hat eine Vielzahl weiterer Einstellmöglichkeiten, und um die geht es diesen Monat.

Bytecode-Analyse im Eigenbau

Im Java Magazin 12.2014 haben wir uns angesehen, wie man den Classpth scannen kann, ohne Klassen in die JVM zu laden und dann Reflection zu verwenden. Jetzt gehen wir wie angekündigt einen Schritt weiter und analysieren Aufrufketten auf Basis des Bytecodes. Als Beispiel dafür, was damit möglich ist, erstellen wir ein Ranking der am häufigsten aufgerufenen Methoden und suchen die Methoden mit der größten inneren Komplexität heraus. Wie schon letzten Monat verwenden wir dazu die Bytecode-Bibliothek asm.

Classpath-Scan im Eigenbau [Aus der Java-Trickkiste]

Viele moderne Frameworks können zur Initialisierung den Classpath nach annotierten Klassen durchsuchen (z. B. EJB 3, JPA, Spring und sogar Servlet-API 3!). Ich halte diesen Architekturstil für problematisch (Startzeit, Testbarkeit, Security etc.), aber das ist ein Thema für eine andere Kolumne. Und egal wie man zu ihnen steht, Classpath-Scans begegnen einem heutzutage auf Schritt und Tritt – ein Grund, sich die Mechanismen dahinter anzuschauen.

Aus der Java-Trickkiste: Performancemythen

Performance ist ein beliebtes Thema für Entwicklerstammtische. Echte und vermeintliche Best Practices werden – oft als Teil persönlicher Erlebnisse – von Programmierergeneration zu Programmierergeneration weitergegeben. Diesen Monat nehme ich eine Reihe solcher Meinungen unter die Lupe, die mir in Projekten und bei Reviews immer wieder begegnen.

Java-Trickkiste: Patterns zum Instanziieren von Klassen

Diesen Monat stelle ich einige Patterns zum Instanziieren von Klassen vor. Bei Coaching und Codereviews erlebe ich, dass viele Entwickler sich weitgehend auf Default-Konstruktoren und DI-Frameworks beschränken – was nicht per se schlecht ist, aber es gibt für manche Situationen bessere Alternativen. Wenn das eine oder andere bekannt vorkommt: umso besser. Es geht hier nicht darum, bahnbrechende neue Ideen zu präsentieren, sondern ein paar im Prinzip bekannte Lösungen in Erinnerung zu rufen.

Aus der Java-Trickkiste: Referenzen mit Sonderstatus

Dass es Weak, Soft und Phantomreferenzen gibt, ist inzwischen recht allgemein bekannt. Und man kann mit ihnen sogar praktische Probleme lösen – ein guter Grund, sie näher unter die Lupe zu nehmen. Die drei speziellen Referenztypen haben gemeinsam, dass sie von der Garbage Collection besonders behandelt werden. Das ist im C++-Quelltext der JVM fest implementiert, man kann also nicht einfach neue Arten von Referenzen mit Sonderbehandlung einführen.

JDBC-Treiber selbstgebaut [Java-Trickkiste]

Vor vielen Jahren hatte ich mit einem System zu tun, das bei bestimmten Eingabewerten Daten verfälscht in der Datenbank ablegte. Das Phänomen gab dem ganzen Team Rätsel auf, zumal das unser erstes Projekt mit einem O/R Mapper war und wir also keine Intuition für mögliche Fehlerursachen hatten.

Überraschende Effekte mit Java Reflection

Wenn ein Feld einer Klasse final ist, muss man es im Konstruktor initialisieren. Danach behält es seinen Wert, solange das Objekt lebt. Oder doch nicht? Dieser Artikel betrachtet die Möglichkeiten, nachträglich die Werte von Feldern zu ändern, die als final deklariert sind. Man kann damit wilden Schabernack treiben. Es gibt aber auch sinnvolle Anwendungsbereiche dafür. Aber fangen wir mit der skurrilen Seite des Themas an.

Die Tücken bei der Performancemessung [Java-Trickkiste]

„Ausprobieren“ ist ein verbreitetes Verfahren, um zu überprüfen, wie viel Zeit ein verdächtiges Stück Code tatsächlich benötigt. Dabei kann aber überraschend viel schiefgehen … Vor einiger Zeit arbeitete ich an einer Messaging-Middleware mit. Dort wurden viele UUIDs erzeugt, und das Profiling deutete darauf hin, dass Aufrufe von UUID.randomUUID() spürbaren negativen Einfluss auf die Gesamtperformance hatten.

  • 1
  • 2