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.

Die Garbage Collection der Oracle-JVM ist dafür zuständig, nicht mehr benötigten Speicher wieder freizugeben. Und oft tut sie das selbst mit ihren Default-Einstellungen so gut, dass man kaum merkt, dass es sie gibt.

Die letzten beiden Kolumnen haben seiteneffektfreie Programmierung mit Java vorgestellt und gezeigt, wie Code dadurch besser les- und testbar werden kann. Sogar die Performance kann gewinnen, wenn man unveränderliche („persistente“) Collections mit passenden Algorithmen verwendet.

In der letzten Folge von „Aus der Java-Trickkiste“ haben wir seiteneffektfreies Programmieren betrachtet, was in Java im Wesentlichen Klassen bedeutet, bei denen alle Attribute final sind. Das hat den Vorteil, dass man Objekte herumreichen kann, ohne sich Gedanken machen zu müssen, wer sie verändern könnte – kurzum, es hilft dabei, robusten Code zu schreiben.

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.

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.

In der letzten Folge der Java-Trickkiste habe ich über Class Loading geschrieben. Darauf ist von mehreren Seiten die Bitte gekommen, das Thema zu vertiefen. Das mache ich gern und blicke dabei hinter die Kulissen einiger Frameworks.

Java lädt und initialisiert Klassen über einen ausgefeilten Mechanismus. Damit kommt man zwar im Programmieralltag nicht oft in Berührung, es hilft aber z. B. dabei, das Verhalten von Application Servern zu verstehen.

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.

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.

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.

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.

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.

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.

Zur letzten Ausgabe der Java-Trickkiste kam als Feedback die Bitte, das Verhalten von volatile genauer zu erklären. Also gibt es in dieser Folge ein paar überraschende Codebeispiele mit Erklärungen. 

Moderne Systeme arbeiten eigentlich immer mit mehreren Threads. Und manchmal muss man sich trotz Frameworkunterstützung selber darum kümmern, wie mehrere Threads auf dieselben Daten zugreifen.

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.

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.

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.

„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.