Eine der vielen Funktionen des Spring-Frameworks ist die Fähigkeit, Ressourcen beim Herunterfahren der Anwendung automatisch aufräumen zu lassen. Dieser Artikel verschafft einen Überblick über die Möglichkeiten die es gibt, und wie man diese nutzt.

Mehr

Da diese Woche Java 11 erschienen ist (wie kürzlich hier berichtet), konnte ich es nicht lassen, ein klein wenig damit herumzuspielen.

Insbesondere war ich neugierig auf JEP-330, also der Möglichkeit, Java-Dateien direkt auszuführen zu können, ohne sie vorher kompilieren zu müssen. Voraussetzung ist, dass sich das komplette Programm innerhalb einer einzigen Java-Datei befindet.Mehr

Am gestrigen Dienstag, den 25.09.2018 war es soweit: ein halbes Jahr nach Erscheinen der Vorversion hat Java 11 den Meilenstein „GA“ – das heißt „General Availability“ – erreicht und ist somit öffentlich verfügbar.Mehr

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.

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

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

After updating the JAX-WS libraries of my current project to version 2.3.0, I got an error message in the log file when starting up Tomcat:

We’re using Tomcat 8.5, running with Java 8.

The presence of the file module-info.class within the jar file points out to the fact that version 2.3.0 of JAX-WS is ready to be used with Java 9. With the module info, a module of the Java Platform Module System declares other modules on which it depends, as well as the packages it wants to expose to other modules.

When analyzing the jar file I found that, while the Java classes have been compiled with Java 7, the module-info.class was (unsurprisingly) compiled with Java 9.  No wonder that a ClassFormatException occurs when running the application with Java 8.

So what to do with the exception?

• Just ignore it, since it does no harm
• Disable JarScanner
• Run Tomcat with Java 9