VMWare Tenzu hat Spring Framework 7 veröffentlicht. Das quelloffene Framework für die Java-Plattform bringt im aktuellen Release unter anderem neue Funktionen für verbesserte Resilienz, Null Safety, API-Versionierung und Java-Messaging.

Beim JDK zielt Spring Framework 7 auf das aktuelle Java 25, und für Enterprise-Java ist Jakarta EE 11 die Basis. Für das Zusammenspiel mit Kotlin setzt es auf Version 2.2 der Programmiersprache, und für Unit-Tests arbeitet es mit JUnit 6.0 zusammen.

Null Safety mit JSpecify

Um Fehler durch den Umgang mit Null-Pointern zu verhindern – der Erfinder der Null-Referenz Tony Hoare hat sich 2009 für den „Milliarden-Dollar-Fehler“ entschuldigt –, setzt das aktuelle Spring Framework auf JSpecify. Damit gelten die bisherigen Annotationen nach dem JSR 305 (Java Specification Request) als überholt (deprecated).

JSpecify bietet Annotationen, die Null-Pointer-Fehler verhindern helfen: @Nullable zeigt an, dass der Wert potenziell null sein kann, während mit @NonNull annotierte Typen niemals null sein dürfen.

Weitere Details zu den Vorteilen von JSpecify zeigt ein Beitrag auf dem Spring-Blog.

Resilienz für Spring-Anwendungen

Das Spring-Team hat neue Features für die Resilienz eingeführt, die das nun in den Ruhestand geschickte Projekt Spring Retry ersetzen. In Spring Framework 7 sind die Features in org.springframework.core.retry enthalten, das unter anderem RetryTemplate und RetryPolicy enthält.

Die Annotation @Retryable legt unter anderem fest, wie oft und mit welcher Verzögerung die Anwendung versuchen soll, einen fehlgeschlagenen Aufruf zu erneuern, wie folgendes Beispiel aus der Spring-Dokumentation zeigt:

@Retryable(
  includes = MessageDeliveryException.class,
  maxAttempts = 5,
  delay = 100,
  jitter = 10,
  multiplier = 2,
  maxDelay = 1000)
public void sendNotification() {
    this.jmsClient.destination("notifications").send(...);
}

Ob die Resilienzfunktionen greifen oder ignoriert werden, lässt sich über die Konfiguration @EnableResilientMethods festlegen.

API-Versionierung, Java-Messaging und mehr

Spring Framework 7 führt ein neues Konzept für die API-Versionierung ein. Entwicklerinnen und Entwickler konfigurieren, wie die API-Version aufgelöst und validiert wird. Clients können die API-Version bei Anfragen an den RestClient, WebClient und für HTTP-Clients festlegen. Auch im Testing lässt sich die Versionierung mit dem WebTestClient nutzen. Ein Beitrag auf dem Spring-Blog bringt eine detaillierte Ausführung zur API-Versionierung.

Spring bekommt im aktuellen Release zudem den JMSClient, der Funktionen zum Versenden und Empfangen von Nachrichten über die JMS-API (Jakarta Messaging) bietet.

Nennenswert ist zudem noch der neue RestTestClient als Variante des WebTestClient, der den RestClient um ein Testing-Interface erweitert. Außerdem gibt es mit dem Interface BeanRegistrar eine neue Methode, um Beans zu registrieren.

Weitere Neuerungen und einige entfernte oder als überholt markierte Funktionen lassen sich den Release Notes zu Spring 7 entnehmen.

(rme)

Vom 11. bis 14. November 2025 ist Atlanta in den USA das Zentrum von Kubernetes und Cloud-Native. Auf ihrer Hausmesse KubeCon + CloudNativeCon NA feiert die Cloud Native Computing Foundation (CNCF) ihr 10. Jubiläum. Die Veranstaltung ist wie immer vollgepackt mit Neuerungen aus der Welt von Cloud-Native.

Einfacheres Kubernetes-Versionsmanagement

Das Flaggschiff-Projekt der CNCF, Kubernetes, wartet ebenfalls mit Neuerungen auf. Seit wenigen Tagen lässt sich ein Upgrade der Control-Plane auf Unterversionsebenen rückgängig machen. Startend mit Version 1.33 können Administratoren beispielsweise von 1.35 auf 1.34 zurückgehen, falls es Probleme mit der neueren Version gibt. Technisch funktioniert das über einen kleinen Trick: eine emulierte Version. Nach dem Upgrade der Binärdateien verhalten sich diese zunächst wie die alte Version. Sie emulieren also die Vorgänger, es ist aber neuer Code. Kommt es zu Problemen, ist der Rücktausch der Binärdateien einfach. Die emulierte Version hatte sich nicht geändert (siehe Abbildung 1).

Doch damit nicht genug. Es lassen sich nun auch Versionen im Upgrade-Prozess überspringen. Wollte man bislang von Version 1.33 auf 1.35 wechseln, dann war der „Umweg“ über 1.34 nötig. Dieser entfällt jetzt. Beide Änderungen sind Teil desselben KEPs (Kubernetes Enhancement Proposals).

Neue Helm-Hauptversion nach sechs Jahren

Helm, der defacto-Standard als Paketmanager für Kubernetes, ist nun in Version 4.0 verfügbar. Dies ist die erste neue Hauptversion seit sechs Jahren. Helm war eines der ersten Projekte unter der Schirmherrschaft der CNCF und ist seit Juni 2018 dabei. In Version 4 haben die Helm-Entwickler das SDK (Software Development Kit) überarbeitet. Es verwendet nun die Logging-Schnittstelle von Go und kann auch die neuesten Funktionen der aktuellen Kubernetes-Version nutzen. Außerdem ist dabei ein neues Plug-in-System. Anwender können nun auch WASM (Web Assembly) einsetzen. Damit sollten die Plug-ins auf einfache Weise plattformübergreifend verwendbar sein.

Auch unter der Motorhaube fanden große Umbauten statt. Da ist natürlich das Entfernen von altem Ballast und die Verwendung neuester Funktionen. Sichtbar für Anwender sind neue Chart-Features. Helm fährt dabei zweigleisig. Über eine Versionierung (v3) lassen sich aber neue Funktionen ausprobieren. Die bisherigen Charts (v2) funktionieren weiter wie gewohnt. Im Gespräch mit iX erklärt Helm-Entwickler Matt Butcher, dass Stabilität und Kompatibilität von Anfang an wichtige Aspekte von Helm waren. Mit der Versionierung der Charts sei nun Innovation ohne Gefährdung der gesetzten Standards möglich.

Cloud-Native und KI wachsen zusammen

Natürlich ist auch auf dieser Konferenz Künstliche Intelligenz (KI) omnipräsent. Laut Jonathan Bryce (seit Juni 2025 Chef der CNCF) bleibt das auch auf absehbare Zeit so. Cloud-Native und KI wachsen zusammen. Ein jüngst erschienener Bericht sagt, dass sich 41 Prozent der professionellen KI-Entwickler als Cloud-Native bezeichnen. In Zahlen ausgedrückt sind das über sieben Millionen Leute. Der prozentuale Anteil von KI auf Kubernetes-Clustern wächst ebenfalls. Laut CNCF lag er im August 2025 bereits bei 60 Prozent. Jonathan Bryce gibt das neue Ziel vor und sagt: In den vergangenen 10 Jahren war es Aufgabe der CNCF, die Entwicklung von Kubernetes und Co. zu fördern und zu unterstützen. Die nächsten 10 Jahre gilt es, das Gleiche für das Fundament für KI zu tun. Dabei stehen nicht zwingend KI-Agenten im Fokus. Es geht vielmehr darum, die Infrastrukturen für Training und Inferenz aufzubauen, die als Fundament für die KI-Agenten erforderlich sind.

Was gibt es Neues in der CNCF-KI-Welt? Den Anfang macht natürlich Kubernetes. DRA (Dynamic Resource Allocator) ist mit Kubernetes 1.34 für alle verfügbar. Er behandelt GPUs oder auch FPGAs ebenso wie CPUs und ist damit sofort für KI-Anwendungen geeignet. Neu ist außerdem die „Agent Sandbox„. Das Projekt will das Verwalten von einzelnen KI-Applikationen als auch Agenten vereinfachen. Dazu gehört die Entwicklung von CRDs (Customer Resource Definitions) und Kontrollern für Kubernetes. Das Projekt ist noch sehr jung, die ersten Code-Zeilen stammen vom August 2025.

Kubernetes-AI-Conformance-Programm

Gemeinsam mit der CNCF hat die Kubernetes-Community ein KI-Konformitätsprogramm entwickelt. Das Kubernetes-AI-Conformance-Programm definiert Standards und Anforderungen, um die entsprechenden Anwendungen stabil und auch interoperabel betreiben zu können. Dazu gehört beispielsweise die Unterstützung der APIs von DRA und des Kubernetes Gateway. Das Konformitätsprogramm ist ein Prozess, der nicht kostenlos ist und idealerweise am Ende ein Zertifikat übergibt.

Zentrale Registratur für alle KI-Artefakte

Unter den weiteren Neuigkeiten auf der KubeCon findet sich die agentregistry von Solo.io. Die Idee dahinter ist, eine zentrale Registratur für alle KI-Artefakte zu schaffen, beispielsweise MCP-Server (Model Context Protocol), Agenten oder schlichte Informationen. Es gibt damit einen singulären Punkt für die Pflege, Verwaltung und insbesondere auch zum Implementieren von Richtlinien und Sicherheit. Das Projekt steht noch ganz am Anfang und ist nur wenige Wochen alt.

Auch alteingesessene Softwarehersteller sind längst auf den KI-Zug aufgesprungen, beispielsweise Oracle mit der AI Datenbank 26ai. Unter Verwendung von LLMs und MCP-Servern lassen sich Abfragen über KI-Agenten-basierte Arbeitsabläufe ausbauen. Damit sollen sich die Ergebnisse korrekter oder umfangreicher gestalten und bei Bedarf sogar zusätzliche Daten anfordern lassen. Anwenderinnen und Anwender können sogar KI-Agenten innerhalb der Datenbank definieren und ausführen. Der Vorgang lässt sich direkt über die REST-Schnittstelle oder über MCP-Server starten.

Oracle hat zudem eine KI-Agent-Spezifikation entwickelt, die den Einsatz mit verschiedensten Rahmenwerken und Arbeitsabläufen der unterschiedlichen Mitspieler in diesem Umfeld ermöglichen soll. Derzeit sieht der Vorstoß nach einer alleinigen Oracle-Initiative aus. Mit kagent gibt es allerdings ein CNCF-Projekt, das eine ähnliche Ausrichtung hat. In diesem Fall ist Kubernetes als Fundament und Rahmenwerk festgelegt.

(map)

Das Unternehmen Docker, Inc. hat Version 4.50 von Docker Desktop veröffentlicht. Die Entwicklungsumgebung für Container-Anwendungen liefert unter anderem einige auf Developer zugeschnittene Neuerungen, darunter kostenfreie Debug-Funktionen, erweiterte KI-Features für das Bauen von Anwendungen und mehr Kontrolle bei unternehmensweiten Sicherheitsrichtlinien.

Debugging und IDE-Integration für alle Nutzer

Docker Debug – bisher nur in kostenpflichtigen Abonnements verfügbar – steht ab sofort allen Nutzern kostenfrei parat und soll sich noch besser in VSCode, Cursor und vergleichbare IDEs integrieren. Mit dem Dockerfile-Debugger in der VSCode-Extension beispielsweise können Entwicklerinnen und Entwickler Build-Prozesse direkt im Editor Schritt für Schritt durchlaufen. Windows-Nutzer sollen von höherer Stabilität bei der WSL2-Integration profitieren.

Um den Prozess von den ersten Entwicklungsschritten bis zum produktiven Bereitstellen von Anwendungen zu beschleunigen, steht mit Compose-to-Kubernetes eine Funktion bereit, die lokale Multi-Service-Anwendungen in produktionsreife Kubernetes-Deployments übersetzt. Ergänzend unterstützt das cagent-Toolkit beim Entwickeln von Agenten. Mit cagent lassen sich spezialisierte Agenten bauen und betreiben, die über individuelle Kenntnisse und Fähigkeiten verfügen. Dank Support für MCP-Server lassen sich dabei auch externe Tools und Dienste einbinden.

MCP-Integration mit über 270 Servern

Über das Docker MCP Toolkit erhalten Entwicklerinnen und Entwickler nun Zugriff auf über 270 MCP-Server im Docker MCP Catalog, darunter mehr als 60 Remote-Server mit integrierter OAuth-Authentifizierung. Auch One-Click-Verbindungen für Claude Code und Codex sind verfügbar. Die OAuth-Integration soll die Credential-Verwaltung vereinfachen, Services wie Notion und Linear lassen sich direkt anbinden, ohne Token manuell verwalten oder Config-Files pflegen zu müssen.

Docker führt zudem Dynamic MCPs ein, die es KI-Agenten ermöglichen, Tools autonom zu entdecken, zu konfigurieren und zu kombinieren. Die Funktionen Smart Search und Tool Composition erlauben den Agenten, den MCP-Katalog zu durchsuchen, die benötigten Tools zu laden und Code für Multi-Tool-Workflows zu generieren. Die Ausführung erfolgt in einer abgeschirmten Umgebung, die zu reduzierter Token-Nutzung und weniger Context-Bloat beitragen soll.

Security-Funktionen ohne Workflow-Unterbrechung

Mit Docker Desktop 4.50 sollen sich auch das Umsetzen von Sicherheitsmaßnahmen sowie die Einhaltung organisationsübergreifender Security Policies nahtlos in die Entwicklungsprozesse integrieren. Administratoren können unter anderem Proxy-Einstellungen via macOS Configuration Profiles zentral vorgeben sowie PAC-Files (Proxy Auto-Configuration) und Embedded PAC Scripts über Installer-Flags für macOS und Windows spezifizieren. Ein schnellerer Release-Zyklus mit kontinuierlichen Updates soll darüber hinaus gewährleisten, dass Entwickler automatisch die neueste stabile Version mit Sicherheits-Patches erhalten.

Die Docker CLI verarbeitet nun auch Zertifikate von Certificate Authorities (CAs), die negative Seriennummern verwenden. Zwar schreibt der X.509-Standard positive Seriennummern vor, einige Enterprise-PKI-Systeme liefern dennoch nicht regelkonforme Zertifikate. In diesen Fällen mussten Organisationen bisher zwischen dem Einhalten ihrer CA-Konfiguration oder dem Erhalt der Docker-Kompatibilität entscheiden.

Weitergehende Informationen

Docker Desktop 4.50 steht in verschiedenen Versionen für Windows, macOS und Linux zum Download bereit. Weitergehende Informationen und mehr Details zu den Neuerungen finden sich in den Release Notes und im Docker-Blog.

(map)