Status quo des Java-Ökosystems 2024

Werfen wir zunächst einen Blick auf die in der Produktion am häufigsten verwendeten Java-Versionen.

Früher hat Oracle neue Versionen nur bei größeren Updates und Änderungen im JDK veröffentlicht. Jetzt gibt Oracle alle sechs Monate eine neue Java-Version heraus – in der Regel im März und September – und jedes Release enthält neue Funktionen und Bugfixes. Alle zwei Jahre veröffentlicht Oracle eine neue LTS(Long-Term-Support)-Version von Java mit Updates zur Verbesserung der Stabilität, Sicherheit und Performance. Dies ist für Entwickler:innen häufig einer der wichtigsten Faktoren für ein Upgrade der Java-Version.

Im September 2023 brachte Oracle Java 21 auf den Markt. Dies war ein bedeutender Meilenstein für Java mit deutlichen Verbesserungen an Vorschaufunktionen in Form von virtuellen Threads und aktualisierten Bibliotheken sowie mit Neuerungen an der Syntax, die Java auf Augenhöhe mit vielen moderneren Sprachen bringen.

In den sechs Monaten nach der Veröffentlichung von Java 21 verwendeten 1,4 % der von New Relic überwachten Anwendungen Java 21. Zum Vergleich: In den sechs Monaten nach der Einführung von Java 17 nutzten nur 0,37 % der Anwendungen Java 17, also 287 % weniger.

Dabei übertraf die Nutzungsrate von Java 17 bei weitem das, was die Entwicklungs-Community bei der Einführung von Java 11 erlebte. Noch 2023 nutzten 9 % der Anwendungen Java 17 in der Produktion – mittlerweile sind es 35 %. Das entspricht einer Wachstumsrate von fast 300 % innerhalb eines Jahres. Es hat Jahre gedauert, bis Java 11 auch nur annähernd dieses Niveau erreichte.

Weniger als 2 % der Anwendungen nutzten Nicht-LTS-Versionen von Java, was verständlich ist, da diese in der Regel nicht in der Produktion eingesetzt werden.

Sehen wir uns nun die gängigen JDK-Anbieter an.

Java war früher Closed-Source oder proprietär, d. h. Entwickler:innen konnten das JDK nur direkt von Sun Microsystems herunterladen. Doch etwa zehn Jahre nachdem Sun Microsystems die erste Version von Java veröffentlicht hatte, brachte Oracle die erste Open-Source-Version von Java heraus. OpenJDK pflegt diese Version und gestattet Entwickler:innen sowie Anbietern wie Microsoft und Amazon die Pflege anderer Versionen des JDK.

So war Oracle mit rund 75 % Marktanteil im Jahr 2020 der populärste Anbieter von Java-SDKs. Nach der restriktiveren Lizenzierung von JDK 11 gab es eine spürbare Abkehr von Oracle-Binärdateien (bevor man mit Java 17 zu einer offeneren Haltung zurückkehrte), und seitdem ist ein stetiger Rückgang im Jahresvergleich zu verzeichnen. Während Oracle im Jahr 2022 seinen Spitzenplatz noch behaupten konnte (34 %), lag der Marktanteil 2023 bei 29 % und heute bei nur noch 21 % – das entspricht einem Rückgang um 28 % innerhalb eines Jahres.

Amazon vergrößerte seinen Marktanteil 2023 auf 31 % (von 2,2 % im Jahr 2020 und 22 % im Jahr 2022). Dieser sank jedoch 2024 auf 18 % – ein Rückgang von 43 % im Vergleich zum Vorjahr.

Der aufsteigende Stern in diesem Jahr ist Eclipse Adoptium, dessen Verbreitung im Vergleich zum Vorjahr um 50 % von 12 % auf 18 % gestiegen ist. Da Eclipse Adoptium von der Community verwaltet wird, wird dieses JDK tendenziell häufiger aktualisiert als die JDKs von Oracle und Amazon.

Java Garbage Collectors (GCs) sind Speicherverwaltungskomponenten, die dazu dienen, Speicherlecks zu verhindern, die Speichernutzung zu optimieren und insgesamt die Performance und Stabilität von Java-Anwendungen zu gewährleisten.

Einige Java-Versionen unterstützen nur bestimmte GCs. Welchen GC Entwickler:innen verwenden, hängt also teilweise von ihrer Java-Version ab.

Seit Java 11 ist der Garbage-First (G1) GC der Standard. Das könnte erklären, warum 43 % der Kund:innen ihn verwenden und warum es einen so großen Sprung in der Nutzung von Java 11, 17 und 21 im Vergleich zu Java 7 und 8 gab. Einer der Hauptvorteile von G1 ist außerdem, dass er kleinere Bereiche löscht, anstatt große Bereiche auf einmal zu löschen. Das optimiert den Prozess. Außerdem bleibt die Ausführung nur selten hängen und es können sowohl die neue als auch die alte Generation gleichzeitig bearbeitet werden, was es zu einer hervorragenden Wahl für Entwickler:innen macht.

An zweiter Stelle folgt der Serial GC (37 %), der sich ideal für Anwendungen oder Systeme eignet, die auf einem einzigen Prozessor laufen oder bei denen eine große Anzahl virtueller Java-Maschinen (JVMs) auf demselben Rechner ausgeführt werden. Außerdem ist der CPU- und Speicher-Overhead im Vergleich zu komplexeren GCs geringer, sodass er sich für ressourcenbeschränkte Umgebungen eignet.

Die Daten von New Relic zeigen einen Anstieg um 18 % im Vergleich zum Vorjahr bei Anwendungen, die mit vier oder weniger Prozessorkernen laufen.

Gerade in Cloud-Umgebungen, in denen Container häufig zum Einsatz kommen, ist es durchaus sinnvoll, die Ressourcennutzung sparsamer zu halten. Bei bestimmten Anwendungen können damit allerdings auch unerwartete Probleme einhergehen. Dies gilt insbesondere für viele der Vorteile der parallelen („concurrent“) Ausführungsmethodik des standardmäßigen G1 GC auf aktuellen JVMs: Bei Zuweisung von weniger als zwei Kernen sind diese nicht mehr realisierbar. Denn sämtliche mit nur einem Prozessorkern ausgeführten Instanzen könnten genauso gut den seriellen Collector nutzen, wofür dann auch die ihm zugehörigen Performance-Kosten anfallen.

Bei allen Softwareanwendungen und Systemen kann es in der Test- oder Produktionsumgebung zu Fehlern und Problemen kommen. Um solche Probleme zu finden und zu beheben, verwenden Entwickler:innen Logging-Tools. Logging ist jedoch nur dann sinnvoll, wenn es die erforderlichen Informationen aus den Lognachrichten liefert, ohne die Performance der Anwendung zu beeinträchtigen. Software-Entwickler:innen verwenden verschiedene Logging-Frameworks, um diese Probleme zu lösen. So nutzen 91 % aller Java-Anwendungen, die Daten an New Relic übermitteln, Logging-Frameworks.

Das am häufigsten verwendete Logging-Framework war Log4j, das 76 % der Java-Anwendungen nutzen, gefolgt von JBoss Logging (61 %) und Logback (52 %).

Die meisten Java-Entwickler:innen (83 %) verlassen sich auf SLF4j, ein Framework, das als Abstraktion für andere Java-Logging-Frameworks dient. SLF4j ermöglicht es Softwareentwickler:innen, das Logging-Framework ihrer Wahl zu verwenden, und lässt zu, dass Anwendungen zu jedem beliebigen Java-Logging-Framework wechseln können, ohne die Implementierungen zu beeinflussen oder Änderungen vorzunehmen. Damit macht SLF4j Anwendungen unabhängig von Logging-Frameworks und bietet mehr Flexibilität und Portabilität für das Logging in jedem Systembereich. Außerdem bedeutet dies, dass Java-Anwendungen mehr als ein Logging-Framework verwenden können.

Mehr als ein Drittel (41 %) der Java-Anwendungen, die Daten an New Relic übermitteln, verwenden Verschlüsselungsbibliotheken: 17 % nutzen Bouncy Castle, 16 % verwenden Spring Security und 6 % verwenden Jasypt. Bouncy Castle ist seit vielen Jahren dank seiner Cipher Suites und Dienstprogramme eine beliebte Verschlüsselungsbibliothek.

Obwohl bislang nur 0,09 % der Entwickler:innen Amazon Corretto Crypto Provider (ACCP) verwenden, erwarten wir, dass diese Bibliothek in naher Zukunft für mehr Anwendungen genutzt wird, da Unternehmen und Entwickler:innen versuchen, Anbieter zu konsolidieren – und weil sie in der Regel eine bessere Leistung bietet.

Bei den Datenbanken ist Oracle Database am weitesten verbreitet. 17 % der Java-Anwendungen, die Daten an New Relic melden, nutzen diese Datenbank. Oracle Database ist bekannt für seine Skalierbarkeit und die Fähigkeit, große Datenmengen schnell und effizient zu verwalten. Daher ist es in der Regel das bevorzugte Datenbanksystem für Unternehmen. Darüber hinaus bietet es Kundensupport und eine Reihe zuverlässiger Tools.

An zweiter Stelle folgt PostgreSQL, das von 14 % der Java-Anwendungen, die Daten an New Relic übermitteln, verwendet wird. Während Oracle Database direkt von Oracle verwaltet wird und über eine Lizenz verfügbar ist, ist PostgreSQL eine Open-Source-Datenbank, die kostenlos genutzt werden kann und bevorzugt für die Verwaltung von Lese- und Schreibvorgängen sowie komplexen Abfragen eingesetzt wird.

An dritter Stelle steht MySQL, das 13 % der Java-Anwendungen verwenden. MySQL ist ebenfalls eine Open-Source-Datenbank. Es bietet weniger Funktionen als Oracle Database und PostgreSQL, was es stabiler und schneller bei der Verarbeitung macht, insbesondere bei schreibgeschützten Abfragen.

PostgreSQL hat im letzten Jahr an Popularität gewonnen, da es die SQL-Spezifikationen besser erfüllt und mehr Funktionen als MySQL unterstützt. MySQL ist zwar nach wie vor eines der führenden Datenbanksysteme, doch es ist nicht zu verkennen, dass PostgreSQL aufholt.

Wir haben außerdem untersucht, welche Java-bezogenen Fragen Entwickler:innen dem GenAI-Assistenten für Observability New Relic AI stellen. Die Daten zeigen, dass es seit Januar 2024 bei 34 % der insgesamt 483 Java-bezogenen Fragen um die Suche nach Anweisungen ging, 21 % waren Fragen nach bestimmten Metriken, 14 % Fragen zur Konfiguration und bei 14 % der Fragen drehte es sich um Fehlerbehebung.

Einige beispielhafte Fragen und Prompts:

• Wie kann ich API-Aufrufe in meinem Java Spring Boot loggen?
• Muss ich den Agent neu konfigurieren, wenn ich das Java-Framework von Tomcat auf JBoss umstelle?
• Erstell mir ein Dashboard für die Container-Speicherauslastung im Vergleich zur JVM-Heap-Auslastung.
• Diese überwachte Anwendung verwendet das Vaadin-Framework in Java. Es hat eine hohe Speichernutzung. Woran könnte das liegen?
• Was bedeutet in der JVM die Heap-Nutzung von G1 Eden Space?