Java 11 kurz angetestet

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

Zip Slip – Gefahr beim Entpacken von Zipdateien mit Java

Das Security-Team von Snyk hat eine Schwachstelle entdeckt und veröffentlicht, die das Entpacken von Zipdateien mit Java betrifft. Die „Zip Slip“ getaufte Verwundbarkeit sowie Möglichkeiten zur Ausnutzung derselben sind auf der Seite Zip Slip Vulnerability beschrieben.

Betroffen sind vor allem Webanwendungen die es Nutzern erlauben, gepackte Dateien (zip, rar, jar, 7zip etc.) hochzuladenEntwickler solcher Anwendungen sollten unbedingt prüfen ob ihr Code betroffen ist!

Mehr

Local Variable Type Inference in Java 10

Die Local Variable Type Inference ist sicherlich das Feature für das Java 10 bekannt ist – ähnlich wie Generics bei Java 5, oder Lambdas und Streams bei Java 8.

Java 10 ist nun auch schon wieder über einen Monat alt. Höchste Zeit also, um sich das wohl bedeutendste Feature des Releases mal ein wenig näher anzuschauen.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

Unable to process Jar entry [module-info.class] from Jar

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