GraalVM Native Image übersetzt Java-Anwendungen vorab in ein natives Binary. Der Start dauert dann Millisekunden statt Sekunden, der Speicherbedarf sinkt deutlich, und zur Laufzeit wird keine JVM mehr benötigt. Für Anwendungen, die auf jedem Knoten eines Kubernetes-Clusters mitlaufen, sind das gute Argumente. Im konkreten Beispielprojekt, in dem sich ein schwer zu findender Fehler eingeschlichen hatte, ging es genau um Kubernetes Infrastruktur: Ein eigener CSI-Treiber wird als DaemonSet betrieben und belegt so Ressourcen auf jeder einzelnen Node.

Damit diese Optimierungen funktionieren, verschiebt Native Image Arbeit vom Programmstart in den Build. Dazu gehört die Klasseninitialisierung: Statische Initializer werden nicht zwangsläufig beim Start ausgeführt, sondern können bereits beim Bau des Binaries laufen. Deren Ergebnis wandert als fertiges Objektnetz in den sogenannten Image Heap. Keine Initialisierung mehr zur Laufzeit, keine Arbeit für einen Just in Time Compiler.
Das ist zum einen der Hebel für den Geschwindigkeitsgewinn aber gleichzeitig eine Fehlerquelle, die in der klassischen JVM-Welt so nicht existiert. Was ein statischer Initializer ableitet und ermittelt, wird einmalig zum Buildzeitpunt auf der Buildmaschine ausgeführt.

Die NullPointerException ist nach wie vor einer der häufigsten Laufzeitfehler in Java-Anwendungen. Das eigentliche Problem ist selten der einzelne vergessene Check, sondern dass an keiner Stelle festgehalten ist, welche Werte überhaupt null sein dürfen und welche nicht. Diese Information steckt bestenfalls im Kopf der Entwickler oder in der Dokumentation, aber nicht im Typsystem.

JSpecify ist ein herstellerübergreifender Satz von Annotationen, der genau diese Information ausdrückt. Mit Spring Framework 7 und Spring Boot 4 ist das gesamte Spring-API mit diesen Annotationen versehen. Damit die Annotationen nicht nur Dokumentation bleiben, braucht es ein Werkzeug, das sie prüft. Im Maven-Build übernimmt das Error Prone zusammen mit dem NullAway-Plugin von Uber.

Wer Claude, Codex und Co. bei der Entwicklung von Spring-Anwendungen einsetzt, musste vielleicht auch schon feststellen, dass gerade neue Features des Frameworks nicht optimal verwendet werden. Aufgrund fehlender oder veralteter Trainingsdaten erzeugen die Sprachmodelle zwar korrekten, aber nicht optimalen Code. Sie definieren Beans, obwohl diese mittlerweile aus einer Autoconfiguration kommen, nutzen veraltete Klassen (z. B. JdbcTemplate statt JdbcClient) oder entpacken munter JARs, um den aktuellen Quellcode von Spring zu lesen.

In diesem Beitrag zeige ich, wie man mit Spring AI einen Model-Context-Protocol-Server (MCP-Server) für LLMs bereitstellt, der hier Abhilfe schafft. Der Server gibt Agents Zugriff auf die Spring-Dokumentation, die für das aktuelle Projekt relevant ist.

Am 10. Juni 2026 traf sich die Java User Group Münster zu ihrem Vortragsabend bei der LVM Versicherung am Kolde-Ring. Auf der Agenda stand das Thema Agentic AI, vorgetragen von Lars Röwekamp. Die trion GmbH gehört zu den Hauptsponsoren der User Group und unterstützt damit den fachlichen Austausch in der Region.

Den Abend organisierte und moderierte Thomas Kruse. Agentic AI hat deutlich über 100 Teilnehmer angezogen, was die Relevanz unterstreicht.

Large Language Models sind längst kein Forschungsthema mehr – sie landen in Produktivanwendungen. Spring AI bringt die gewohnte Spring-Philosophie in die KI-Integration: einheitliche Abstraktionen über verschiedene Anbieter, automatische Konfiguration per Spring Boot und typsichere APIs. Dieser Beitrag zeigt, wie man in wenigen Schritten einen ChatClient aufbaut, Prompts parametrisiert und strukturierte Java-Objekte aus Sprachmodell-Antworten gewinnt.

Wie geht es meiner Anwendung eigentlich? Wer hierauf eine präzise Antwort haben möchte, muss die richtigen Daten sammeln. Tut man es nicht, ist man blind unterwegs und kann bei Problemen erst spät reagieren. In diesem Artikel beschreibe ich daher, wie man einfach und standardisiert Observability-Daten seiner Spring-Boot-Anwendung sammelt.

Die IP-Adresse eines Clients stellt für Web-APIs einen wichtigen Datenpunkt dar. Sie wird für Anwendungsfälle wie der Personalisierung von Diensten, Protokollierungen und auch für Sicherheitsaspekte wie z.B. Rate Limiting benötigt. In diesem Artikel soll es daher darum gehen, wie sich die tatsächliche IP-Adresse eines Clients in einer Spring Boot Anwendung zuverlässig und sicher ermitteln lässt.

Um eine Anwendung vor unliebsamen Traffic wie Spam oder andere Formen von automatisierten Requests zu schützen, können Rate Limits genutzt werden. In diesem Artikel beschreibe ich, wie sich Rate Limits pro IP-Adresse in einer Spring Boot Anwendung umsetzen lassen.

Im heutigen Software-Entwicklungsalltag ist Security ein entscheidendes Thema. Moderne Java-Anwendungen bestehen zu einem erheblichen Teil aus Fremdbibliotheken. Diese sollten regelmäßig auf den neusten Stand gebracht werden, auch um möglichen Sicherheitslücken entgegenzuwirken.

Wie im Vorgängerartikel Build-Warnungen bei Dependency-Updates beschrieben, machen externe Abhängigkeiten oft über 90% des Codes in Microservices aus. Neben der Aktualität der Bibliotheken ist es besonders wichtig, bekannte Sicherheitslücken (CVEs) zu erkennen und rechtzeitig Gegenmaßnahmen einzuleiten.

Das OWASP Dependency-Check-Maven-Plugin bietet eine praktische Lösung, um aus dem Build-Prozess heraus auf mögliche Sicherheitslücken in Abhängigkeiten aufmerksam zu machen. Im Folgenden stelle ich vor, wie sich das Plugin in eine Spring-Boot-Anwendung sowie eine GitLab CI-Pipeline integrieren lässt.

Micronaut ist ein modernes Java Framework, das speziell mit der Anforderung entwickelt wurde, den Einsatz von Reflection zu minimieren.
Dazu wird unter anderem Code Generierung zur Build Zeit verwendet. Micronaut kann mit Maven als auch Gradle als Buildsystem gut verwendet werden. Mit IntelliJ IDEA gibt es jedoch einiges zu beachten, sonst kann es zu schwer diagnostizierbaren Fehlern kommen.