Legacy AutoClosable

Nichts ist ärgerlicher bei der Verbesserung von Legacy Software als die Abhängigkeit von Klassen, die sich modernen Sprach Konstrukten verweigern. Eine besondere Gruppe dabei sind all die Klassen, die sich zieren vom Interface AutoClosable zu erben. Diese Klassen sind durch veraltete Abhängigkeiten in das eigene Projekt geflossen und diese Abhängigkeiten sind aus mannigfaltigen Gründen dem Zugriff des Entwicklers entzogen.

Finger weg von Apache Commons

Wenn es eine beliebte Sammlung von Bibliotheken für Java Entwickler gibt, dann ist dies wohl Apache Commons. Für jede Art von Problem eines Java Entwickler gibt es dort eine Methode, die eine einfache Lösung verspricht.

Technische Schulden – Tilgen, Tilgen, Tilgen

Hin und wieder geben aktuelle Diskussionen den Anstoß über gerne und häufig verwendete Begriffe einmal etwas genauer nachzudenken. Im diesem Fall über die Technischen Schulden. Was ist damit gemeint und wie ist mit ihnen umzugehen?

Bug Pattern in Eigenbau

Im verherigen Beitrag zur statischen Code Analyse mit Error Prone wurde die Möglichkeit erwähnt, eigene Bug Pattern prüfen zu lassen. In diesem Beitrag wird nun ein BugChecker implementiert, der ein störendes Bug Pattern erkennt und patchen kann.

Fehler entfernen mit Error Prone

Menschen machen Fehler und Software Entwickler benehmen sich in dieser Hinsicht auch sehr menschlich. Um die Zahl der Fehler in den Programmen zu reduzieren wurden daher schon früh verschiedene Vermeidungsstrategien entwickelt. Dies bekanntesten Strategien sind Tests und die statische Code Analyse.
Die Hauptaufgabe der Tests ist die Prüfung der korrekten Arbeitsweise der Software. Dafür wird das tatsächliche Verhalten mit dem erwünschten Verhalten verglichen. Die statische Code Analyse verfolgt eine andere Zielsetzung. Hier wird der Quellcode nach fehlerhafter oder unvorteilhafter Verwendung diverser Sprach-Konstrukte durchsucht. Bekannte Tools zur statische Code Analyse sind Checkstyle, PMD und SonarLint. In diesem Beitrag geht es um das Tool Error Prone aus dem Hause Google.

@Deprecated Deadlock

Beim Aktualisieren von Bibliotheken finden sich immer wieder Methoden, die nicht mehr zeitgemäß sind. Denn häufig ermöglichen neuere Ansätze kompakteren, einfacheren oder eleganteren Code. Um den Nutzern der Bibliothek das Leben nicht zu erschweren, werden solche Methoden als veraltet (@Deprecated) markiert. Damit beginnt eine Gnadenfrist, in der die Nutzer ihren eigenen Code auf die neuen Alternativen umbauen müssen. Diese Frist endet, wenn die Entwickler der Bibliothek die veralteten Methoden löscht.

Der Rete Algorithmus (3)

Im zweiten Beitrag zum Rete Algorithmus wurde eine erste einfache Implementierung vorgestellt. Schon bei der Umsetzung zeigte sich jedoch, dass diverse Details anders gelöst werden sollten. Es passiert recht häufig, dass sich eine zu enge Anlehnung an eine Beschreibung eines Algorithmus den Weg zu einer guten Lösung erschwert oder sogar verbaut. Aus ähnlichen Gründen blieb mir viele Jahre der Zugang zu einer korrekten Double-Array-Trie Implementierung versperrt. Auch dort bedurfte es erst einen neuen Zugang zum Thema um die Blockade zu beenden.

Implementierungen inkrementell verändern mit dem Branch By Abstraction Pattern

Um eine bestehende Software Komponente umzubauen erstellt der Software Entwickler in der Regel einen Feature-Branch. In diesem Feature-Branch werden alle notwendigen Änderungen vorgenommen und das Ergebnis zurück in den Haupt-Branch gemerged. Unangenehm wird dieses Vorgehen, wenn die Änderungen aufwendig und langwierig sind. Denn je länger die Änderungen dauern, desto schwieriger wird es, die Änderungen in den Haupt-Branch zu integrieren. Dies liegt weniger an den Änderungen im Feature-Branch, sondern an den zwischenzeitlichen Änderungen am Haupt-Branch, der durch andere Feature-Branches unaufhörlich verändert wird. Eine Möglichkeit der Merge-Hölle von langlebigen Branches zu entgehen ist das Branch By Abstraction Pattern.

Unterschiede finden mit dem Java Annotation Processor (Teil 2)

Im ersten Beitrag wurde die Implementierung eines AnnotationProcessor vorgestellt, der Vergleichsklassen erzeugte. Um zwei Instanzen einer Klasse ExampleBean zu vergleichen, muss nur ein spezielles Interface definiert werden, um automatisch eine passende Implementierung zu erhalten.

Ab die Post (Teil 2)

Im vorherigen Beitrag zu JavaMail API wurde die Bibliothek GreenMail vorgestellt. Mit dieser Bibliothek ist es möglich, verschiedene E-Mail Server zu simulieren. Da keine überzeugende JUnit 5 Unterstützung existiert, lag die Idee nahe, eine eigene JUnit Extension zu schreiben. Während der Implementierung zeigten sich erste Ideen als unnütz, das Verständnis der GreenMail API verbesserte sich und die eigene Art zu Testen wirkte sich natürlich auf die Gestaltung der Erweiterung aus.