Developer

Aktuelle Themen

Scala Pattern Matching am Beispiel des Bowlinggame-Katas

Alle zwei Wochen treffen sich einige //er zum Coding Dojo. Dort lösen wir alle 2 Wochen gemeinsam Katas und andere Aufgaben, um voneinander zu lernen und uns stetig zu verbessern. Bei einem solchen Treffen ist die Idee für diesen Blogbeitrag entstanden. Wir haben zusammen das Bowlinggame-Kata in verschiedenen Sprachen (Java, Scala und Kotlin) gelöst. Die Lösung in Scala ist am kürzesten und unterscheidet sich am meisten im Vergleich zu den anderen beiden. Deshalb stellt dieser Beitrag unsere gefundene Scala-Lösung und das Scala Pattern Matching vor.

Mehr

Fehlende Abhängigkeiten bei mvn clean in Maven Multi-Modul-Projekt

In einem Maven-Projekt mit mehreren Modulen hatte ich kürzlich dass Problem, dass unter bestimmten Umständen die Ausführung des Befehls mvn clean fehlschlug. Laut Fehlermeldung konnten gewisse Dependencies nicht aufgelöst werden:

Bei den Dependencies aus der Fehlermeldung handelte es sich um Module des Projekts, das mit clean gesäubert werden sollte. Der Fehler trat während der Ausführung von clean in module-one auf, das wiederum module-two als Abhängigkeit hat.

Voraussetzung für den Fehler war, dass die genannten Module noch nie mit mvn install gebaut worden waren, d.h. die Module sich noch nicht im lokalen Maven-Repository befanden. Das kommt beispielsweise vor nachdem die Versionsnummer  geändert wurde, oder wenn das Projekt noch gar nie gebaut worden ist.

Nun sollte man denken, dass bei einem mvn clean die Abhängigkeiten keine Rolle spielen. Tun sie in der Regel auch nicht. Wie sich jedoch herausstellte, gab es in module-one eine Konfiguration des maven-antrun-plugin, die an die clean-Phase gebunden war (Zeile 8):

Beim Ausführen von mvn clean wurde also nicht nur das Projekt aufgeräumt, sondern auch das maven-antrun-plugin ausgeführt. Das Plugin setzt wiederum das Vorhandensein aller Abhängigkeiten des Moduls voraus.

Die Lösung war, das Antrun-Plugin an eine andere Phase zu binden. Wieso es an der clean-Phase hing konnte ich nicht mehr herausfinden (der Kollege von dem die Konfiguration stammte hatte das Unternehmen mittlerweile verlassen). Jedenfalls bietet der Maven Default Lifecycle eine große Auswahl an alternativen Phasen: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy.

Nach Auswahl und Konfiguration einer Phase die zum ausgeführten Ant-Task passt (in diesem Fall process-sources) lief der mvn clean-Befehl fehlerfrei durch.

JCE Unlimited Strenght Cryptography ab jetzt standardmäßig aktiv

In Oracles Java-Runtimes bis einschließlich Version 1.8.0_151 ist es standardmäßig nicht möglich, die Java Cryptography Extension (JCE) mit starker Verschlüsselung zu verwenden. Demnach dürfen beispielsweise Verschlüsselungen mit dem AES-Algorithmus nur Schlüssel mit einer maximale Länge von 128 bit benutzen. Alle Versuche, einen längeren Schlüssel zu verwenden werden mit folgender Exception geahndet:

Um mit längeren Schlüsseln arbeiten zu dürfen war es vor Java-Versionen vor 1.8.0_151 notwendig, die Java Runtime mit entsprechenden Unlimited Strength Cryptography Policy Files auszustatten (für Java 8 hier erhältlich). In Java 1.8.0_151 müssen diese Policy Files nicht mehr extra installiert werden. Stattdessen kann dort die starke Kryptografie durch setzen der Security Property crypto.policy=unlimited aktiviert werden.

Seit Version 1.8.0_161 ist die Unlimited Strength Cryptography standardmäßig aktiviert. Die Security Property muss also nicht mehr extra gesetzt werden. Soll keine starke Kryptografie erlaubt sein, kann diese mit crypto.policy=limited wieder auf kleine Schlüssellängen begrenzt werden.Mehr

Code Coverage Reports mit Maven in Multi-Modul-Projekten

JaCoCo ist ein sehr nützliches Tool für die Messung der Code Coverage, also der Abdeckung von Produktivcode durch automatisierte Tests, sowie zur Erstellung von Code Coverage Reports. An sich ist das Einbinden des JaCoCo-Maven-Plugins nicht schwierig. Hat man allerdings in einem Maven-Projekt mehrere Module, ist die Konfiguration nicht mehr ganz so trivial. Denn standardmäßig werden Coverage-Reports nur für die einzelnen Module generiert. Um einen aggregierten Report über alle Module hinweg zu erhalten, der die Gesamttestabdeckung des Projekts zeigt, und dabei außerdem zwischen Unit- und Integrations-Tests unterscheiden soll, ist schon etwas mehr Aufwand nötig. Leider gibt es kaum funktionierende Beispiele im Internet. Zudem ist die Dokumentation etwas dürftig, so dass man schon mal eine ganze Weile beschäftigt sein kann bis alles wie gewünscht funktioniert.

Daher haben wir ein funktionsfähiges Beispielprojekt mit drei Modulen erstellt, das als Vorlage für Projekte dienen kann.

Mehr

DBeaver – Ein universeller SQL Client für Datenbanken

Bislang habe ich für die Administration von relationalen Datenbanken das jeweils empfohlene Standardwerkzeug verwendet, was aber oftmals kein Spaß war. An der Stelle erwähne ich nur den Oracle SQL Developer oder pgAdmin 3/4. Das kann doch eigentlich nicht der Ernst der etablierten Datenbankhersteller sein…
Ich jedenfalls bin mit diesen Werkzeugen nie wirklich gut zurechtgekommen. Vor allem störte mich, dass jedes Werkzeug ein unterschiedliches Verhalten sowie eigene Tastaturkürzel mit sich brachte. Also musste hierfür etwas anderes her: DBeaver!Mehr