Cloud-Exit ist aktuell ein heiß diskutiertes Thema – spätestens seit Firmen wie Basecamp angekündigt haben, die Cloud zu verlassen und wieder auf eigene Infrastruktur zu setzen.

In dieser Podcastfolge sprechen Dennis Becker und Jan Gregor Emge-Triebel mit Andreas Lehr, Berater für Cloud- und DevOps-Themen und Herausgeber des Podcasts „Happy Bootstrapping“ sowie des Newsletters „Alles nur gecloud“. Gemeinsam diskutieren sie, was neben hohen Kosten noch für einen Cloud-Exit spricht: von Vendor-Lock-ins über Datenschutz bis hin zu Performance und digitaler Souveränität. Dabei berichtet Andreas Lehr von realen Erfahrungen aus der Praxis.

Einig sind sich die drei, dass Hyperscaler durchaus weiter ihre Berechtigung haben – aber wo genau fängt ein Cloud-Exit an, und wie nah muss ein Unternehmen seinen eigenen Servern wieder kommen, damit sich der Schritt lohnt?

Die aktuelle Ausgabe des Podcasts steht auch im Blog der programmier.bar bereit: „Cloud-Exit mit Andreas Lehr„. Fragen und Anregungen gerne per Mail oder via Mastodon, Bluesky, LinkedIn oder Instagram.

(mai)

Im September 2025 erscheint das OpenJDK 25 mit 18 Java Enhancement Proposals. Die bekannteren Funktionen haben wir uns bereits im vorangegangenen Post angeschaut. Jetzt werfen wir einen Blick auf die Themen, die bei den meisten Entwicklerinnen und Entwicklern etwas weniger Aufmerksamkeit erregen. Mit dabei sind Verbesserungen beim Profiling und Beobachten von laufenden Java-Anwendungen, beim Start und Warm-up, beim Speicherverbrauch und kleinere Änderungen bei Garbage Collectors sowie Erweiterungen bei der Unterstützung von Kryptografie.

JEP 503 – Entfernung des 32-Bit-x86-Ports

Das Entfernen des Quellcodes und Build-Supports für den 32-Bit-x86-Port (nach Deprecation in JDK 24 via JEP 501) zielt darauf ab, neue Features nicht länger mit 32-Bit-Fallbacks bedienen zu müssen, alle 32-Bit-x86-Sonderpfade zu streichen und Build/Test-Infrastruktur zu vereinfachen. Nicht betroffen sind der 32-Bit-Support anderer Architekturen und frühere JDK-Releases. Der Pflegeaufwand stand in keinem Verhältnis zum Nutzen und das Entfernen beschleunigt die Weiterentwicklung (z. B. bei Loom, FFM API, Vector API, …).

JEP 509 – Genauere CPU-Profile mit JFR (experimentell, nur für Linux)

Das Entwicklerteam hat den JDK Flight Recorder (JFR) so erweitert, dass er auf Linux den CPU-Zeit-Timer des Kernels nutzt und damit präzisere CPU-Profile erstellt. Und das auch dann, wenn Java-Code gerade native Bibliotheken ausführt. Bisher stützte sich JFR vor allem auf einen „Execution Sampler“, der in festen Echtzeit-Intervallen (z. B. alle 20 ms) Java-Stacks zieht. Dabei können Threads in nativem Code übersehen, Proben verpasst und gegebenenfalls nur ein Teil der Threads erfasst werden.

Mit CPU-Zeit-Profiling bildet JFR die tatsächlich verbrauchten CPU-Zyklen ab und vermeidet unsichere, interne Schnittstellen, wie sie manche externe Tools verwenden. Ein Sortieralgorithmus verbringt zum Beispiel seine gesamte Laufzeit auf der CPU und taucht entsprechend stark im CPU-Profil auf. Eine Methode, die meist auf Daten aus einem Socket wartet, beansprucht hingegen kaum CPU-Zeit und erscheint folglich nur geringfügig im Profil.

JEP 518 – Stabileres JFR-Stack-Sampling

Der JFR soll stabiler werden, indem er Java-Thread-Stacks nur noch an Safepoints traversiert und dabei den bekannten Safepoint-Bias so weit wie möglich reduziert. Bisher nahm der JFR in festen Intervallen (z. B. alle 20 ms) asynchron Samples auch außerhalb von Safepoints auf. Das erforderte Heuristiken zum Stack-Parsing, die ineffizient waren und im Fehlerfall sogar JVM-Crashes auslösen konnten (etwa bei gleichzeitigem Class-Unloading). Künftig wird die Profilerstellung der Wanduhrzeit (wall-clock time) weiter unterstützt, aber mit einem robusteren Verfahren, das Genauigkeit und Ausfallsicherheit besser ausbalanciert.

JEP 520 – Exaktes Methoden-Timing und -Tracing mit JFR (via Bytecode-Instrumentierung)

Dieses JEP erweitert den JDK Flight Recorder um eine Bytecode-Instrumentierung, die jeden ausgewählten Methodenaufruf exakt misst und mit Stacktrace aufzeichnet – im Gegensatz zu stichprobenbasiertem Profiling. Methoden lassen sich ohne Codeänderungen zielgenau per Kommandozeile, Konfigurationsdatei, jcmd oder JMX auswählen. Nicht vorgesehen sind das Aufzeichnen von Argumenten/Feldwerten, das Tracen nicht-bytecodierter Methoden (z. B. native, abstract) sowie das gleichzeitige Instrumentieren sehr vieler Methoden. In solchen Fällen bleibt Sampling der richtige Ansatz. Um lange Startzeiten zu analysieren, lassen sich statische Initialisierer ausgewählter Klassen gezielt tracen. So wird sichtbar, welche Initialisierung sich auf später verschieben lässt oder wo ein jüngst eingespielter Fix tatsächlich Laufzeit spart.

JEP 514 – AOT-Caches leichter erstellen

Dieses JEP vereinfacht das Erzeugen von Ahead-of-Time-Caches (AOT), die den Java-Start deutlich beschleunigen: Für gängige Fälle soll ein einziger Schritt genügen, der Trainingslauf und Cache-Erstellung kombiniert. Ziel ist es, die bislang nötige Zwei-Phasen-Prozedur (erst record, dann create mit separater AOT-Konfiguration) abzulösen – ohne an Ausdrucksstärke zu verlieren und ohne neue AOT-Optimierungen einzuführen. Ein Beispiel aus dem Status quo: Heute braucht man zwei java-Aufrufe und bleibt mit einer temporären *.aotconf-Datei zurück. Künftig entfällt dieser Ballast, was unter anderem Frameworks wie JRuby bei eigenen Trainingsläufen entgegenkommt. Für Spezialfälle bleiben die expliziten AOT-Modi und Konfigurationsoptionen weiterhin verfügbar.

JEP 515 – Schnellere Warm-up-Phase durch Profile aus dem AOT-Cache

Die JVM (Java Virtual Machine) kann jetzt beim Start Methodenausführungsprofile aus einem früheren Lauf laden, sodass der JIT direkt die voraussichtlich heißen Methoden kompiliert, statt zunächst Profile sammeln zu müssen. Die Profile werden in einem Training Run erzeugt und über den bestehenden AOT-Cache bereitgestellt. Dafür sind keine Codeänderungen und keine neuen Workflows nötig. Warm-up kostet heute Zeit, weil HotSpot erst während der Produktion herausfindet, welche Methoden es zu optimieren gilt. Verlagert man das Profiling in den Training Run, erreicht die Anwendung in Produktion schneller ihre Spitzenleistung. Ein Webdienst beispielsweise, der sonst erst nach einigen Minuten Profil-Sammeln voll performant ist, kann mit vorab aufgezeichneten Profilen schon beim Start die kritischen Request-Pfade kompilieren und so schneller unter Last reagieren.

JEP 470 – PEM-Encoding API (Preview)

Dieses JEP führt eine einfache API ein, um kryptografische Objekte — Schlüssel, Zertifikate und Sperrlisten — in das weit verbreitete PEM-Textformat (RFC 7468) zu kodieren und daraus wieder Objekte zu dekodieren. Sie unterstützt die Standardrepräsentationen PKCS#8 (Private Keys), X.509 (Public Keys, Zertifikate, CRLs) sowie PKCS#8 v2.0 (verschlüsselte Private Keys und asymmetrische Schlüssel). Bisher fehlte in Java eine komfortable PEM-API. Entwickler mussten Base64, Header/Footer-Parsing, Factory-Auswahl und Algorithmus-Erkennung selbst erledigen. Die neue Preview-API reduziert diesen Boilerplate deutlich.

JEP 510 – API für Key Derivation Functions (Finalisierung in JDK 25)

Dieses JEP finalisiert (unverändert gegenüber der Preview in JDK 24) eine API für Key Derivation Functions (KDFs), etwa HKDF (RFC 5869) und Argon2 (RFC 9106). Sie ermöglicht den Einsatz von KDFs in KEM/HPKE-Szenarien (z. B. ML-KEM, Hybrid Key Exchange in TLS 1.3), erlaubt PKCS#11-basierte Implementierungen und räumt auf, indem JDK-Komponenten wie TLS 1.3 und DHKEM auf die neue API statt auf interne HKDF-Logik umgestellt werden. Aus einem gemeinsamen Geheimnis (z. B. ECDH-Shared-Secret) und einem Salt lässt sich per HKDF deterministisch ein Satz Sitzungsschlüssel für Verschlüsselung und MAC ableiten. PBKDF1/2 wandern übrigens nicht in die neue API, sie bleiben wie bisher über SecretKeyFactory nutzbar.

JEP 519 – Kompakte Objekt-Header (Finalisierung in JDK 25)

Die kompakten Objekt-Header gelten mit dem Update nicht mehr als experimentell, sondern als offizielles Produktfeature. Sie gelten jedoch nicht als Standard-Layout. Seit ihrer Einführung in JDK 24 (JEP 450) haben sie sich in Stabilität und Performance bewährt – getestet mit der vollständigen JDK-Testsuche bei Oracle und in Hunderten von Amazon-Services (teils auf JDK 21/17 zurückportiert). Experimente zeigen deutliche Vorteile: bis zu 22 Prozent weniger Heap, 8 Prozent weniger CPU-Zeit, 15 Prozent weniger GCs (G1/Parallel), und ein hochparalleler JSON-Parser läuft zehn Prozent schneller. Damit verbessert der geringere Overhead pro Objekt die Speichernutzung und Cache-Lokalität, was spürbar Start-up und Durchsatz zugutekommt.

JEP 521 – Shenandoah (generational), Finalisierung in JDK 25

Der generationale Modus des Shenandoah-GC wechselt vom experimentellen in den Produktstatus (eingeführt als Experiment in JDK 24 via JEP 404). Der Standard bleibt unverändert, per Default nutzt Shenandoah weiterhin eine Generation. Die Umstufung basiert auf zahlreichen Stabilitäts- und Performance-Verbesserungen sowie umfangreichen Tests (u. a. DaCapo, SPECjbb2015, SPECjvm2008, Heapothesys); Anwender berichten von erfolgreichen Einsätzen unter Last. Zum Aktivieren des generationalen Modus ist -XX:+UnlockExperimentalVMOptions nicht mehr nötig. Alle übrigen Optionen und Defaults bleiben gleich und bestehende Startskripte funktionieren weiter.

Java 25: stabil und durchdacht

Beim Blick auf die Vielzahl der sehr unterschiedlichen neuen und erneuerten Features zeigt sich, dass Java 25 auch wieder ein spannendes Release ist. Auch wenn für uns Entwickler auf den ersten Blick scheinbar gar nicht so viel Neues dabei ist. Vieles sind Wiedervorlagen aus früheren Preview-Versionen. Aber genau das zeigt, wie stabil und durchdacht sich Java weiterentwickelt. Und außerdem ist enorm viel unter der Haube passiert: von Performance-Optimierungen über Sicherheitsverbesserungen bis hin zu Weichenstellungen für die Zukunft, etwa in der Kryptografie und der Speicherverwaltung. Java bleibt damit eine moderne, leistungsfähige Plattform. Und im März 2026 steht mit dem OpenJDK 26 die nächste Version vor der Tür. Die Versionen 25 und 26 sind übrigens die einzigen, die mit der Jahreszahl ihrer Erscheinung übereinstimmen. Ab Java 27 müssen wir dann wieder überlegen, welche Version gerade aktuell ist.

Zum Vertiefen der hier genannten JEPs empfiehlt sich als Startpunkt die OpenJDK-25-Projektseite. Und es gibt natürlich auch eine ausführliche Liste aller Änderungen in den Release Notes. Zudem lohnt sich auch immer mal ein Blick auf die JEP-Drafts. Dort warten noch einige Themen auf ihre Veröffentlichung, wie Light-Weight JSON API, Null-Restricted and Nullable Types, Value Classes and Objects oder Integrity by Default. Uns Java-Entwicklern dürfte in Zukunft also nicht so schnell langweilig werden.

(mdo)

Moin.

Im Allgemeinen finden wir Demokratie toll. In Unternehmen ist davon nicht viel zu merken. Vorgesetzte werden selten von den Mitarbeiterinnen und Mitarbeitern gewählt. Und abgewählt werden sie schon gar nicht. Und wie sieht es eigentlich im Hinblick auf Demokratie im Team aus?

Formal sind in den meisten Teams alle Mitglieder gleichberechtigt. Die Realität sieht meist anders aus: Es gibt Rollen, Zuständigkeiten und unterschiedliche Machtverhältnisse. Davon ist manches unausgesprochen und Teil der Teamkultur. Wenn daraus schlechte Entscheidungen entstehen, kann es sich lohnen, die Entscheidungshoheit im Team zu hinterfragen. Wie das geht, zeigt das folgende Beispiel.

Ich habe als Teamcoach mit einem Team in der Frontendentwicklung zusammengearbeitet. In der Kennenlernphase habe ich erste Gespräche mit allen Teammitgliedern geführt. Dabei habe ich auch gefragt, was gut und was schlecht läuft. Von den meisten Gesprächspartnern habe ich die Rückmeldung bekommen, dass sie das Framework für die Frontendentwicklung nicht mögen. Es ist proprietär und es gibt keine aktuelle Doku. Eine bessere Alternative sei beispielsweise Angular. In einem Gespräch ging es so weit, dass der Entwickler darüber nachdachte, zu kündigen. Seine Sorge war, dass er sein Können und damit seinen Marktwert verlieren würde, wenn er noch ein paar Jahre in diesem Umfeld arbeitete. Ich teilte seine Einschätzung.

Nun stellt sich natürlich die Frage, weshalb das Team mit diesem ungeliebten Framework arbeitete. Handelte es sich um eine Vorgabe des Unternehmens? Gab es technische Abhängigkeiten, die einen Wechsel unmöglich machten?

Selbstentwicklung als Ballast

Nein, nichts davon. Der Grund, der mir genannt wurde, lautet: Das eingesetzte Framework war die Selbstentwicklung eines Teammitglieds. Für den weiteren Verlauf nenne ich diese Person „Bob“. Mehrere Ansätze, Bob dazu zu bringen, ein anderes Framework zu verwenden, haben nichts gebracht; so wurde es mir zumindest erzählt.

Abgesehen von Bob waren alle Teammitglieder externe Entwickler. Ich hatte den Verdacht, dass es die Haltung „Der Kunde ist König“ gab und man glaubte, als Dienstleister kein Mitspracherecht zu haben. Um das zu hinterfragen, habe ich das Thema in einer Retrospektive in den Mittelpunkt gestellt: „Wie treffen wir in unserem Team Entscheidungen?“

Ich stelle die Frage nicht im luftleeren Raum, sondern bevorzugt anhand von aktuellen, relevanten Beispielen. Dazu frage ich das Team als Erstes: „Welche Entscheidungen, die in der Vergangenheit getroffen wurden oder regelmäßig getroffen werden, beeinflussen Euch und die Arbeit des Teams am meisten?“ Die Antworten teile ich in zwei Gruppen: Dinge, die außerhalb des Teams von anderen Personen und Dinge, die innerhalb des Teams entschieden werden. Nur über die zweite Gruppe lohnt es sich zu sprechen, wenn man konstruktive Ergebnisse erhalten möchte und nur das Team anwesend ist.

Typische Beispiele für Antworten sind: Welche Datenbank verwenden wir? Welches Repo verwenden wir? Wie sehen unsere Coding-Regeln aus? Welche Testabdeckung wollen wir erreichen? Wie sieht unser Branching-Workflow aus?

Ob das Team zu diesem Zeitpunkt auch die konfliktbehafteten Entscheidungen anspricht, lässt sich natürlich nicht vorhersagen. Im Fall meines oben genannten Teams kam das problematische Thema auf den Tisch: „Welches Frontend-Framework verwenden wir?“

Sobald die Themen bekannt und priorisiert sind, ordne ich sie in eine Tabelle ein, die wie folgt aussieht.

In der ersten Spalte stehen die Dinge, deren Entscheidungshoheit zu klären sind. Die weiteren Spalten stehen für verschiedene Entscheidungswege. Wird ein Thema nur von einer Person entschieden oder braucht es Einstimmigkeit im Team? Ist eine einfache oder eine absolute Mehrheit erforderlich? Oder genügt eine (einfache) Mehrheit, solange niemand ein Veto einlegt?

Im weiteren Verlauf geht das Team in zwei Schritten, Zeile für Zeile, durch. Der erste Schritt dient dazu, den Status quo zu ermitteln: „Wie entscheiden wir das Thema bisher?“ (Ist-Zustand) Zur Antwort markiert jedes Teammitglied die Spalte, die seiner Meinung nach den bisherigen Entscheidungsmodus darstellt.

In meinem obigen Beispiel sah die Tabelle nach diesem Schritt wie folgt aus.

Alle fünf Teammitglieder waren sich einig: Die Frage, welches Frontend-Framework zum Einsatz kommt, wurde und wird nur von einer Person entschieden (markiert durch die bleibenden Punkte). Der zweite Schritt ist der spannende: Wie wollen wir das Thema in Zukunft entscheiden? (Soll-Zustand)

Bei dieser Frage habe ich folgendes Ergebnis erhalten:

Zur Überraschung aller Beteiligten war sich das Team auch hier einig: Welches Framework zur Anwendung kommt, ist eine Teamentscheidung. Mehr noch: Ein Veto einer einzelnen Person würde eine Mehrheitsentscheidung blockieren.

Angesichts der bisherigen Erzählung war ich (und einige Entwickler) von verhärteten Fronten ausgegangen. Durch die einfache Übung, die auch unter dem Namen Team Decision Matrix bekannt ist, kam das Team ins Gespräch und es eröffnete sich die Möglichkeit, ein (neues) Framework auszuwählen, das das Team gemeinsam als zukunftstauglich einstufte.

Erst lesen, dann hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.

(rme)