Kategorie: Java

Erkenntnisse und Problemlösungen rund um die Java-Programmierung

Veröffentlicht am

Maven Dependencies und Plugins aktuell halten – der pragmatische Guide

 

Regelmäßige Dependency-Pflege ist keine Kür, sondern ein fester Teil stabiler Softwareentwicklung.

Warum das überhaupt wichtig ist

Veraltete Dependencies sind nicht nur unschön, sondern konkret riskant:

  • Sicherheitslücken in Bibliotheken wie Jackson oder Log4j
  • Inkompatibilitäten mit neueren JDK-Versionen
  • Build-Probleme durch veraltete Maven-Plugins
  • technische Schulden, die spätere Upgrades unnötig teuer machen

Regelmäßige Updates sorgen deshalb nicht nur für Sicherheit, sondern auch für planbare Wartung.

Kurzfassung für Eilige

Wenn Du nur einen alltagstauglichen Standardprozess willst, reicht oft schon das hier:

mvn versions:display-property-updates
mvn versions:display-plugin-updates
mvn versions:display-dependency-updates
mvn versions:update-properties -DallowMajorUpdates=false
mvn clean test

Das wichtigste Tool: versions-maven-plugin

Das zentrale Werkzeug für diesen Workflow ist das Versions Plugin:

mvn versions:display-dependency-updates

Du musst es in der Regel nicht separat installieren – Maven lädt es automatisch nach.

  • zeigt verfügbare Updates an
  • hebt Versionen automatisch an
  • aktualisiert Properties
  • beschränkt Updates auf Minor oder Patch

1. Veraltete Versionen erkennen

Dependencies prüfen

mvn versions:display-dependency-updates

Beispielausgabe:

commons-lang3 ............ 3.12.0 -> 3.20.0
jackson-databind ........ 2.13.4 -> 2.20.0

Plugins prüfen

mvn versions:display-plugin-updates

Gerade alte Plugins sind oft eine unterschätzte Ursache für Build-Probleme.

Properties prüfen

Wenn Du Versionen zentral über Properties pflegst, bekommst Du die sauberste Update-Strategie:

<junit.version>3.11.0</junit.version>

Dazu passt dieser Befehl:

mvn versions:display-property-updates

Effektives POM verstehen

mvn help:effective-pom

Damit erkennst Du geerbte Versionen, Parent-POM-Einflüsse und aktive Profile – also genau die Stellen, an denen Versionskonflikte oft entstehen.

2. Updates durchführen

Variante A: direkt gesetzte Versionen

mvn versions:use-latest-releases

Variante B: Properties aktualisieren

mvn versions:update-properties

Beispielsweise von:

<junit.version>3.3.2</junit.version>

auf:

<junit.version>3.5.0</junit.version>

Parent-POM aktualisieren

mvn versions:update-parent

3. Nur sichere Updates ohne Major-Sprünge

Hier liegt der eigentliche Hebel für einen stabilen Alltag.

Nur Minor- und Patch-Updates zulassen

mvn versions:update-properties -DallowMajorUpdates=false
  • 5.1 → 5.9 erlaubt
  • 5.x → 6.x blockiert

Nur Patch-Updates zulassen

mvn versions:update-properties \
-DallowMajorUpdates=false \
-DallowMinorUpdates=false
  • 5.1.1 → 5.1.9 erlaubt
  • 5.1 → 5.2 blockiert

4. Sicherer Workflow für den Alltag

Ein bewährter Ablauf sieht so aus:

mvn versions:display-property-updates
mvn versions:display-plugin-updates
mvn versions:display-dependency-updates

Danach entscheidest Du Dich für eine Strategie:

Konservativ

mvn versions:update-properties -DallowMajorUpdates=false

Aggressiv

mvn versions:update-properties

Danach immer testen:

mvn clean test

5. Änderungen rückgängig machen

mvn versions:revert

Oder Änderungen dauerhaft übernehmen:

mvn versions:commit

6. Best Practices aus der Praxis

Versionen zentral über Properties steuern

<junit.version>3.5.4</junit.version>

Plugins konsistent referenzieren

<maven-surefire-plugin.version>3.5.4</maven-surefire-plugin.version>

Verwendung dann über:

${maven-surefire-plugin.version}

Regelmäßige Updates einplanen

  • monatlich prüfen
  • quartalsweise Major-Upgrades evaluieren

Fazit

Maven bringt alles mit, was Du für saubere Dependency-Pflege brauchst. Entscheidend ist nicht nur das Update selbst, sondern die Strategie dahinter: Properties nutzen, Major-Updates bewusst steuern und lieber regelmäßig prüfen als selten mit einem großen Big-Bang-Upgrade reagieren.

  • mehr Transparenz über veraltete Komponenten
  • automatisierte und steuerbare Updates
  • bessere Kontrolle über Stabilität und Risiko
Veröffentlicht am

JAVA Eclipse Access restriction: The constructor […] is not API (restriction on required library ‚C:\Program Files\Java\jre1.8.0_181\lib\ext\jfxrt.jar‘)

Völlig ohne Vorwarnung haben meine ganzen Java-Projekte diese Fehlermeldung erhalten:

Access restriction: The constructor  is not API (restriction on required library 'C:\Program Files\Java\jre1.8.0_181\lib\ext\jfxrt.jar')

Lösen ließ sich das ganz einfach. Das Projekt hatte sich als Java-Grundlage eine Runtime (JRE) und kein Development Kit (JDK) gewählt –> Das muss einfach wieder umsgestellt werden auf JDK.

Alternativ kann man die Berechtigung auch für das betroffene Projekt vergeben:

In ein Properties des Projekts

  • Java Build Path –> Libraries
  • Acess Rules –> Edit und Add
  • Als Wert „javafx/**“ (in meinem Fall) hinzufügen.

Anschließend Apply und Rebuild –> Problem gelöst 🙂

Veröffentlicht am

Java – MySql – Beim Insert die angelegte ID des Primary Keys zurück bekommen

Beim Programmieren hatte ich eine für mich neue Anforderung: Ich wollte direkt nach dem Insert in die Datenbank den Primary Key des angelegten Datensatzes zurück bekommen. Die Lösung fand sich schnell im Netz und ich will sie aber für zukünftige Recherchen meinerseits gleich hier in meinem „Knowledge-Fundus“ hier hinterlegen:

String insertQuery = "INSERT INTO TABLE (…) VALUES (?,?,?)";
PreparedStatement ps = db.prepareStatement(query, Statement.RETURN_GENERATED_KEYS);
ps.setInt(1,…);
ps.setInt(2,…);
ps.setInt(3,…);
ps.execute();
ResultSet rs = ps.getGeneratedKeys();
Integer idPrimarykey = null;
if (rs.next()){
idPrimarykey=rs.getInt(1);
}
return idPrimarykey;

Das Kommando klappt in meinem Beispiel hervorragend mit MySql. Damit konnte ich diekt aus dem Insert den Primary Key ermitteln und direkt weiterverarbeiten.

Veröffentlicht am

Nicht druckbare Zeichen in Java Strings lassen .equal oder .valueOf(String) fehlschlagen

Beim Vergleichen von Strings mit equal oder Enum Parsen mit „valueOf“ gibt es keinen match, obwohl der String augenscheinlich identisch ist – Dieses Problem wird in diesem Beitrag erläutert:

Beim Parsen von CSV Dateien stößt man ab und zu auf Probleme mit der Encodierung der zu parsenden Datei.

Im konkreten Fall gestaltete sich das Problem als herausfordernd, weil auf den ersten Blick keine Ursache für das Problem erkennbar war.

Die geparste Variable nennt sich „rowTypeString“ und hat im Debugger den Inhalt „RH“

debug screenshot - String "RH" sieht aus als wäre er 2 Zeichen lang, ist aber 3 Zeichen lang wegen nicht druckbarer Zeichen - aus diesem Grund schlägt ein Equal fehl
Augenscheinlicher Inhalt der Variable „rowTypeString“ – nur zwei Zeichen mit dem Inhalt „RH„

Im Quelltext wird jedoch die Variable über ein Enum mit der  „valueOf()“-Funktion geparst und einem eindeutigen Typ zugewiesen. Diese lief jedoch immer auf eine IllegalArgumentException hinaus.
Die Analyse des String ergab dann doch noch interessante Details:

  • Der String hat eine Länge von 3 Zeichen (auch wenn das dritte unsichtbar ist)
  • Ein Character Array gab auch interessante Details zurück:
char of string with hidden character
  • Die Methode rowTypeString.getBytes() gibt  zahlreiche Bytes zurück, welche auf das dritte Zeichen hindeuten:
    [-17, -69, -65, 82, 72]
  • Eigentlich dürfte das ByteArray nur [82,72] lauten für den String „RH“

Die Lösung konnte sich dann doch gut sehen lassen. Es werden alle „nicht druckbaren Zeichen“ entfernt mit dem nachfolgenden regulären Ausdruck:

stringValue.replaceAll("[^\\p{Graph}\n\r\t ]", "");

Ich danke an dieser Stelle dem Verfasser einer Antwort in StackOverFlow

Veröffentlicht am

Eclipse debug stoppt auch ohne eigene Breakpoints

Java-Entwickler, welche mit Eclipse arbeiten, erhalten manchmal nach einem Update von Eclipse oder der Java VM Debugfehler, welche sich nicht auf die eigenen Projektdateien beziehen, sondern auf Breakpoints im Java JDK:

Thread [main] (Suspended (exception FileNotFoundException))
URLClassPath$JarLoader.getJarFile(URL) line: 577
URLClassPath$JarLoader. (URL, URLStreamHandler, HashMap) line: 546
URLClassPath$3.run() line: 324
AccessController.doPrivileged(PrivilegedExceptionAction ) line: not
available [native method]
URLClassPath.getLoader(URL) line: 313
URLClassPath.getLoader(int) line: 290
URLClassPath.getResource(String, boolean) line: 160
URLClassPath.getResource(String) line: 213

17-02-_2016_15-35-00

Auch langes googlen hat mir diesmal nicht geholfen. Meistens gab es Empfehlungen, in den Preferences –> Debug  „Suspend execution on uncaught exceptions“ zu deaktivieren.

17-02-_2016_15-32-29Leider hatte das bei mir nicht geholfen. Was allerdings half, war bei Breakpoints die betroffene Klasse zu deaktivieren bzw. das Häkchen von „Caught locations“ zu deaktivieren.

17-02-_2016_11-20-16Ich hoffe, auch Euch hilft dieser Tipp.