In den vergangenen 30 Jahren hat sich eine rege Community im Java-Umfeld gebildet. Ich habe im Laufe des Jahres einige deutschsprachige Vertreter zu ihren Erfahrungen befragt. Die Resonanz war überwältigend. Vielen Dank an alle, die mitgemacht haben. In diesem zweiten Teil kommen Bernd Müller (Programmkomitee JavaLand und Professor Hochschule Ostfalia), Heinz Kabutz (Java Champion und Java Specialist Newsletter), Patrick Baumgartner (Java Champion, Co-Organisator JUG Schweiz), Wolfgang Weigend (Oracle Deutschland) und Gernot Starke (Buchautor und Gründer von arc42) zu Wort.

Java prägt viele Entwicklerinnen und Entwickler seit ihren ersten Schritten in der IT – und hat in dieser Zeit Höhen, Tiefen und mehrere Neuerfindungen erlebt. Die folgenden Antworten spiegeln persönliche Anfänge, prägende Erlebnisse, kritische Momente und eine Einordnung von Javas Rolle in der heutigen Softwareentwicklung wider. Abschließend wagen sie einen Blick nach vorn: mit Tipps für die eigene Weiterentwicklung und Erwartungen an Java in den kommenden Jahren.

Wann und mit welcher Version bist du erstmals mit Java in Berührung gekommen?

Bernd Müller: 1996, 1.0

Heinz Kabutz: 1.0

Patrick Baumgartner: Meine erste Begegnung mit Java hatte ich während meines Studiums, damals mit Java 1.4. Die Sprache war zu dieser Zeit bereits weitverbreitet, insbesondere in der Unternehmenswelt, und galt als stabil und zuverlässig. Was mich besonders beeindruckt hat, war die Plattformunabhängigkeit – der berühmte „Write Once, Run Anywhere“-Ansatz, der es ermöglichte, Code ohne Anpassungen auf verschiedenen Betriebssystemen auszuführen.

Wolfgang Weigend: Ende des Jahres 1996 bin ich als Senior System Consultant bei Texas Instruments Software erstmals mit der Programmiersprache Java in Berührung gekommen. Meine erste Java-Version war das JDK 1.0. Anfang Juli 1997, habe ich als Senior System Consultant bei Sun Microsystems in Frankfurt am Main begonnen und noch im selben Jahr habe ich die Java-Technologie bei der TLC GmbH (DB AG / DB Systel GmbH) mit der IT-Abteilung bei der Deutschen Bahn eingeführt.

Gernot Starke: Zum „Marktstart“ von Java durfte ich das Object-Reality Centre in Köln leiten, eine Kooperation von Sun Microsystems mit der Kölner Beratungsfirma „Schumann AG“. Das war 1995/1996, und Java war in den USA gerade mit TamTam angekündigt worden. Wir haben seinerzeit auch das allererste deutsche Java-Projekt (gemeinsam mit Sun und der damaligen HypoVereinsbank in München) durchgeführt und in Produktion gebracht.

Was war rückblickend dein schönstes Erlebnis mit der Sprache oder dem Ökosystem Java?

Heinz Kabutz: Es ist eine Sprache mit unendlich vielen Macken, über die man herrliche Rundbriefe schreiben kann.

Patrick Baumgartner: Definitiv die Konferenzen und der Hallway-Track! Java ist nicht nur eine Sprache, sondern eine weltweite Community mit unglaublich engagierten und inspirierenden Menschen. Ich bin oft mit Spring-Themen auf Konferenzen unterwegs und hatte dort die Möglichkeit, mit Gleichgesinnten tief in technische Diskussionen einzutauchen, neue Ideen zu entwickeln und von den Erfahrungen anderer zu lernen. Über die Jahre sind aus diesen Begegnungen nicht nur wertvolle fachliche Kontakte, sondern echte Freundschaften entstanden. Es ist immer wieder spannend, bekannte Gesichter auf Konferenzen wiederzutreffen und gemeinsam über die neuesten Entwicklungen im Java-Ökosystem zu diskutieren – oft auch nach einem Java User Group Talk. Diese Interaktionen, sei es auf einer großen Bühne, in kleinen Gruppen oder ganz spontan auf den Fluren zwischen den Talks, sind für mich eine enorme Bereicherung. Java ist für mich daher weit mehr als eine Technologie – es ist ein Ökosystem, das Menschen verbindet, inspiriert und gemeinsam wachsen lässt.

Wolfgang Weigend: Es waren die vielen Java-Projekte, die von den Entwicklern bei den Unternehmen in Deutschland im Jahr 1998/1999 gestartet wurden. Ein Highlight war, als ich zum ersten Mal die JavaOne-Entwicklerkonferenz in San Francisco mit 25.000 Teilnehmern im Moscone Center besuchte. Diese Eindrücke haben meine Erfahrungen mit der Java Community maßgeblich geprägt.

Gernot Starke: Kann man sich heute kaum noch vorstellen, aber ich konnte plötzlich ohne „#ifdef“-Makros im Code programmieren und meine Sourcen trotzdem auf anderen Betriebssystemen übersetzen. Das Java-Ökosystem: die fast unvergleichlich hohe Vielfalt und Gebrauchstauglichkeit der vielen Open-Source-Komponenten/Frameworks im Java-Umfeld. Da hat Java gegenüber C# ganz eindeutig die Nase vorn. Projekte im Dunstkreis von C, C++ oder C# konnten und können in dieser Hinsicht nur aus einer deutlich eingeschränkten Auswahl von Open-Source-Komponenten/Frameworks schöpfen. Das halte ich für ein riesiges Asset. Weiterhin fand ich vor Jahren die Erfindung von Groovy als alternative Sprache auf der JVM großartig. Die Möglichkeit, in anderen Sprachen zu entwickeln (Kotlin, Scala, Groovy) und dabei die Vorzüge der JVM zu behalten.

Aber es ist nicht alles golden, was glänzt. Was hat dich negativ beeinflusst bzw. was war ein unschöner Moment im Java-Umfeld?

Bernd Müller: Das Verschleppen des Releases von Java EE 8 durch Oracle.

Heinz Kabutz: Mir hat Sun Microsystems mehr gefallen als Oracle, aber leider haben die zu viel Verlust gemacht. Oracle hat aber Java gut geführt.

Patrick Baumgartner: Eines der Dinge, die mich im Java-Ökosystem immer wieder stören, ist das oft unsachliche Java- oder Spring-Bashing. Kritik ist wichtig und notwendig, aber manchmal habe ich das Gefühl, dass bestimmte Diskussionen weniger auf fundierten Argumenten basieren, sondern eher aus Prinzip geführt werden. Technologien entwickeln sich weiter, und natürlich gibt es in jedem Framework oder jeder Sprache Herausforderungen und Fallstricke. Doch statt konstruktiv darüber zu sprechen, wird oft pauschal behauptet, dass Java „veraltet“ oder „zu schwergewichtig“ sei oder dass Spring „zu komplex“ sei. Dabei ignorieren solche Aussagen meist die Gründe, warum diese Technologien in vielen Bereichen so erfolgreich sind und kontinuierlich weiterentwickelt werden. Was ich mir stattdessen wünsche, ist ein offener Austausch auf Augenhöhe – ein Diskurs, der auf Erfahrungen basiert, bei dem sowohl Stärken als auch Schwächen beleuchtet werden. Nur so kann sich ein Ökosystem langfristig weiterentwickeln und verbessern.

Wolfgang Weigend: Es waren unternehmerische Entscheidungen von Sun Microsystems, die an der einen oder anderen Stelle herausfordernd waren, aber sie haben mich in Bezug auf Java nicht negativ beeinflusst. Ich habe mich immer für die ganzheitliche und vorwärtsgerichtete Technologie eingesetzt.

Gernot Starke: Oh, da gibt’s einiges:

• In den frühen Zeiten gab’s keine ordentliche Infrastruktur für Build und Test. „ant“ war nur so mittelgut für Entwicklungsteams.
• Build-Prozesse in früheren Maven-Versionen haben Ewigkeiten gebraucht, das war lange Zeit sehr nervig.
• Die unsäglich schwergewichtigen EJBs und der Versuch, zu viele technische Details auf Java-Application-Server auszulagern. Diese Software-Monstren haben vielen Teams das Leben zur Hölle gemacht. Ich habe Stunden mit dem technischen Support von den großen Herstellern verbracht, weil diese Biester ihre Kinderkrankheiten ewige Zeiten nicht kuriert haben. Der Gipfel war der Vorschlag, das gesamte Server-Betriebssystem neu zu installieren und beim Kompilieren des Betriebssystem-Kernels einige (nicht-Standard-)Parameter zu setzen – dann würde der Bug im Application-Server vielleicht nicht mehr auftreten.
• Grafische Oberflächen für Desktop-Anwendungen in Eclipse-RCP (V2) entwickeln und dann auf eine neuere Version von Eclipse (V3) portieren müssen – ich glaube, unser gesamtes Team hat über Kündigung oder Flucht nachgedacht.
• Der Kauf von Sun Microsystems durch Oracle.
• Dass OSGI niemals so richtig ans Fliegen gekommen ist, bzw. niemals in der Breite der Praxis ankam. Und dass der Versuch, das Java-Modulsystem zu etablieren, leider an der Verweigerung der Praxis gescheitert ist. Ich halte das immer noch für nützlich aus Architektursicht, aber viele Projekte ignorieren das ja beharrlich.

Glaubst du, dass Java auch nach 30 Jahren noch relevant ist? Welche Rolle spielt Java deiner Meinung nach in der modernen Softwareentwicklung, insbesondere im Vergleich zu anderen Sprachen und Technologien?

Bernd Müller: Es ist sehr relevant und spielt eine sehr große Rolle, da es sehr verbreitet ist. Ich glaube, dass Java wartbarer ist als andere Sprachen, sodass wir in einigen Jahren sehen werden, wie große Systeme in anderen Sprachen veralten, da sie nicht mehr gewartet werden (können).

Heinz Kabutz: Java wird noch von sehr vielen großen Unternehmen benutzt. Es ist ein solides System, schnell und zuverlässig.

Patrick Baumgartner: Definitiv! Java hat sich über die Jahre enorm weiterentwickelt und bleibt eine der wichtigsten Sprachen für Unternehmensanwendungen, Cloud-Native-Systeme und verteilte Architekturen. Die kontinuierlichen Verbesserungen – von Lambdas über Records bis hin zu Virtual Threads – zeigen, dass Java am Puls der Zeit bleibt. Natürlich gibt es mit Kotlin, Go oder Rust starke Alternativen, aber Java bietet ein stabiles, performantes und sicheres Ökosystem. Das macht die Sprache für viele Unternehmen und Entwickler weiterhin äußerst attraktiv.

Wolfgang Weigend: Nach meiner Einschätzung ist Java bis heute relevant, insbesondere weil die Verbreitung, Abwärtskompatibilität und Lesbarkeit für sich sprechen. Mittel- und langfristig sehe ich die Programmiersprache Java gut gerüstet, weil Innovation über das OpenJDK ständig einfließen kann. Besonders die Code-Assistenz-Systeme mit den Entwicklungsumgebungen werden existierenden Java-Code durchforsten und mittels KI & ML die Entwickler bei der Bewältigung ihrer Aufgaben effizient unterstützen.

Gernot Starke: Sprachen wie Python, Go und Java/TypeScript haben durch Self-Contained Systems und Microservices kräftig an Aufwind gewonnen. Andererseits haben wir riesige Mengen bestehenden Sourcecodes in Java als kritische Softwarekomponenten in vielen Unternehmen. Daher halte ich Java und das Java-Ökosystem weiterhin für sehr relevant.

Wer Integration-Tests schreibt, kennt das Problem: Entweder man arbeitet mit Mocks, die nur begrenzt die Realität abbilden, oder man kämpft mit langsamen, schwer wartbaren Testumgebungen. Mocks haben den Charme, dass Tests schnell durchlaufen und keine externe Infrastruktur benötigen. Doch sie bergen eine Gefahr: Die Tests werden grün, weil die Mocks perfekt zu den Tests passen. Das heißt nicht unbedingt, dass der Code mit echten Systemen funktioniert. Wer garantiert, dass der Mock das Verhalten einer PostgreSQL-Datenbank oder einer Kafka-Queue korrekt abbildet?

Die Alternative in Form einer dedizierten Testumgebung mit echten Diensten bringt andere Probleme mit sich: Wie setzt man den Zustand zwischen Tests zurück? Wie verhindert man, dass Tests sich gegenseitig beeinflussen? Und wie stellt man sicher, dass die Testumgebung exakt der Produktionsumgebung entspricht?

Mit TestContainers gibt es einen pragmatischen Ausweg: Die Bibliothek startet echte Dienste in wegwerfbaren Docker-Containern. Jeder Test bekommt seine eigene, frische Instanz – komplett isoliert, mit definiertem Startzustand – und nach Testende automatisch aufgeräumt. Der Ansatz ist allerdings nur dann praktikabel, wenn die containerisierten Dienste schnell genug starten. Bei einer Datenbank, die in weniger als einer Sekunde bereit ist, lässt sich für jeden einzelnen Test ein neuer Container hochfahren. Bei Diensten mit mehreren Minuten Startzeit muss man hingegen zu Shared Containers greifen.

Die Idee hinter TestContainers

TestContainers ist ein Projekt zur programmatischen Steuerung von Docker-Containern in Tests. Der Kerngedanke ist simpel: Statt Mocks zu schreiben oder manuelle Testumgebungen zu pflegen, lässt man den Test selbst die benötigte Infrastruktur hochfahren. Nach Testende räumt TestContainers automatisch auf – kein manuelles Stoppen von Containern, keine vergessenen Ressourcen.

Die konzeptionelle Funktionsweise ist schnell erklärt: Ein Test startet einen oder mehrere Container, wartet, bis sie bereit sind, führt die eigentlichen Testschritte durch und stoppt zum Schluss die Container. TestContainers übernimmt dabei die dynamische Portzuordnung, sodass der Test sich nicht um Portkonflikte kümmern muss. Ein integrierter Reaper-Mechanismus sorgt dafür, dass Container auch dann aufgeräumt werden, wenn ein Test abstürzt oder abbricht.

Besonders wichtig sind die Wait Strategies. Ein gestarteter Container ist nämlich nicht automatisch sofort bereit, Anfragen zu verarbeiten. Eine Datenbank braucht beispielsweise Zeit zum Initialisieren, ein Webserver muss zunächst hochfahren. Wait Strategies definieren, wann ein Container als bereit gilt – etwa wenn ein bestimmter Port lauscht, eine HTTP-Anfrage erfolgreich ist oder eine spezifische Logzeile erscheint.

TestContainers bietet dabei bereits für viele gängige Anwendungen und Dienste vorgefertigte Module wie PostgreSQL, MySQL, Redis, MongoDB und Kafka. Diese Module sind Wrapper-Klassen um die generische Container-API, die bereits sinnvolle Defaults mitbringen, etwa Standardports, typische Umgebungsvariablen und passende Wait Strategies.

Für weniger verbreitete Dienste oder eigene Systeme kann man eigene Wrapper schreiben. Sie bauen auf dem GenericContainer auf und kapseln domänenspezifische Konfiguration. Das praktische Beispiel im Folgenden zeigt, wie unkompliziert die Umsetzung ist: eine Klasse, die das Image, Ports und Kommandozeilenparameter konfiguriert und eine Client-Instanz zurückgibt. Der Wrapper abstrahiert die TestContainers-API und bietet eine auf den konkreten Dienst zugeschnittene Schnittstelle.

Auf den ersten Blick scheint Docker Compose eine Alternative zu sein, das ebenfalls Container für Tests starten kann. Der Unterschied liegt jedoch in der Herangehensweise: Docker Compose arbeitet deklarativ mit YAML-Dateien und richtet typischerweise eine geteilte Umgebung für mehrere Tests ein. TestContainers hingegen ist programmatisch und integriert sich direkt in den Testcode. Jeder Test kann seine eigene Containerkonfiguration haben, Container werden im laufenden Betrieb gestartet und wieder gestoppt.

Ein weiterer Unterschied: Bei Compose muss man explizit darauf achten, Container zwischen verschiedenen Tests zurückzusetzen. Bei TestContainers ist das Design von Anfang an auf Isolation ausgelegt. Jeder Test bekommt neue Container, was sie robuster und unabhängiger voneinander macht.

Mehr Idee als Projekt

TestContainers ist kein monolithisches Open-Source-Projekt, sondern eher eine Idee, die in verschiedenen Programmiersprachen umgesetzt wurde. Es gibt TestContainers für Java, Go, .NET, Node.js, Python, PHP, Rust und zahlreiche weitere Sprachen – entwickelt von verschiedenen Maintainer-Teams mit unterschiedlichen Schwerpunkten.

Das bedeutet, dass beispielsweise Features, die in der Java-Implementierung selbstverständlich sind, in der Python-Version fehlen können – und umgekehrt. Auch die API-Gestaltung unterscheidet sich zwischen den Programmiersprachen, selbst wenn die Konzepte gleich bleiben. Die Dokumentationsqualität variiert und die Reife der Implementierungen ebenso.

Die Community und der Support sind pro Sprache organisiert: Hilfe zur Go-Implementierung findet man in anderen Foren als Hilfe zur PHP-Version.

Man sollte nicht davon ausgehen, dass ein bestimmtes Feature existiert, nur weil man es aus einer anderen Sprache kennt. Ein Blick in die Dokumentation der jeweiligen Implementierung ist unerlässlich. Die gute Nachricht: Die Grundkonzepte sind überall gleich. Wer das Prinzip verstanden hat, findet sich grundsätzlich auch in anderen Implementierungen zügig zurecht.

Ein Praxisbeispiel

Um die Unterschiede zwischen TestContainers-Implementierungen konkret zu zeigen, dient die Datenbank EventSourcingDB als Beispiel. Dabei handelt es sich um eine auf Event Sourcing spezialisierte, von the native web entwickelte Datenbank. Sie ist Closed Source, aber die zugehörigen Client-SDKs (Software Development Kits) sind Open Source auf GitHub verfügbar.

EventSourcingDB steht dabei exemplarisch für einen typischen Service, den man in Anwendungen benötigt – sei es eine Datenbank, eine Message-Queue oder ein anderer Infrastrukturdienst. Der entscheidende Vorteil für unser Beispiel: EventSourcingDB startet in weniger als einer Sekunde, was den „Container pro Test“-Ansatz praktikabel macht. Die Client-SDKs für verschiedene Sprachen enthalten jeweils eine eigene TestContainers-Integration, deren Implementierung sich lohnt anzuschauen.

Dieser Artikel betrachtet die Go- und PHP-Implementierung im Detail. Beide verfolgen konzeptionell den gleichen Ansatz, unterscheiden sich aber in wichtigen Details. Daher eignen sich die Implementierungen gut, um die Unterschiede zwischen TestContainers-Implementierungen zu illustrieren.

Im Netz sind Hinweise aufgetaucht, dass nun bald auch Gmail-Nutzer die Mail-Adresse für ihren Google-Account ändern dürfen. Bislang konnten Anwender die Adresse nur wechseln, sofern es sich nicht um eine @gmail.com handelte. Auf einer indischen Supportseite kündigt Google jetzt jedoch an, dass sich das ändern soll.

Auf der Seite in Hindi heißt es: „Wichtiger Hinweis: Die Funktion zum Ändern der E-Mail-Adresse eines Google-Kontos wird schrittweise für alle Nutzer eingeführt. Daher ist diese Option möglicherweise derzeit für Sie nicht verfügbar.“ (übersetzt mit DeepL). Eine Änderung von einer @gmail.com- ist nur in eine andere @gmail.com-Adresse möglich. Die alte Adresse bleibt als Alias bestehen und kann weiter Nachrichten empfangen sowie für das Login verwendet werden.

Auch bereits vorhandene Daten und Nachrichten bleiben erhalten. Eine Änderung ist einmal im Jahr möglich. Dass das Dokument derzeit nur in Indien erscheint, könnte darauf hindeuten, dass Google die Funktion dort vor einem weltweiten Start testen möchte.

(who)