Übersicht
Software ist heute ein so allgegenwärtiger Bestandteil unseres Alltags, wie die Auswahl an Sprachen für ihre Programmierung breit gefächert ist. Zu den populärsten gehört definitiv Java: Die Programmiersprache kommt für die Entwicklung von Software für nahezu jeden Industriezweig und quasi alle Sektoren der Wirtschaft zum Einsatz. Dies zunächst aufgrund ihrer plattformunabhängigen Architektur – in Java geschriebene Software kann bei minimalem Aufwand für unterschiedliche Systeme kompiliert werden. Außerdem stehen für sie tausende Bibliotheken zur Verfügung, und nicht zuletzt zeichnet sich Java auch durch umfassenden Support aus.
Erstmals veröffentlicht im März 2020, bietet unser Report zum Status quo des Java-Ökosystems Einblicke auf Grundlage von Performance-Daten aus Millionen von Anwendungen, die auf der Programmiersprache basieren. Mit dem jüngst veröffentlichten Java 17 steht erstmals seit Version 11 auch wieder ein Release der Programmiersprache zur Verfügung, der durch Long-Term Support (LTS) abgedeckt ist. Die in den Bericht eingeflossenen Daten wurden anonymisiert und um Details bereinigt, die nicht zur allgemeinen Beurteilung des Java-Ökosystems vonnöten sind. Sämtliche Informationen, die für Cyber-Angriffe oder andere böswillige Aktivitäten von Nutzen sein könnten, haben wir aus diesem Report komplett ausgeklammert.
Dieser Report bietet Kontext und Erkenntnisse rund um den Status quo des Java-Ökosystems von heute. Untersucht haben wir dabei folgende Kategorien:
Java 11 – der neue Standard
Java 11 war 2020 zwar bereits seit mehr als einem Jahr verfügbar gewesen. Dominiert wurde das Feld damals jedoch noch klar von Version 8 der Programmiersprache: 84,48 % der Anwendungen basierten damals auf Java 8. Inzwischen haben sich die Mehrheitsverhältnisse zwischen den beiden LTS-Releases jedoch deutlich verschoben. So basieren heute 48 % der in Produktion ausgeführten Java-Anwendungen auf Version 11. Mit diesem deutlichen Zugewinn gegenüber den 11,11 % von 2020 verdrängt sie Java 8 knapp auf den zweiten Platz, das nun nur noch 46,45 % für sich beanspruchen kann.
Java 17 konnte sich dagegen zwar noch nicht bis zur Spitze durchsetzen, dafür aber trotz seiner erst wenige Monate umspannenden Verfügbarkeit bereits jetzt die Versionen 6, 10 und 16 der Programmiersprache hinter sich lassen.
Java 7, für das der Support noch in diesem Jahr eingestellt wird, kommt immerhin noch bei 1,71 % der Anwendungen zum Einsatz. Bei 0,27 % trifft dies auf Version 6 von Java zu, für die der Support bereits ausgelaufen ist. In beiden dieser Fälle gilt jedoch: Die Mehrheit sind um Legacy-Anwendungen, für die keine Upgrades vorgenommen wurden.
Java 14 – die populärste Version ohne LTS
Die Veröffentlichung von Java 9 wurde begleitet von einer neuen Strategie zur Release-Frequenz der Plattform: Alle 6 Monate wurde fortan eine neue Version der Plattform veröffentlicht, die jedoch nur bis zum Erscheinen des nächsten Release unterstützt wurde. Hierdurch sollten neue Features in kürzeren Abständen verfügbar gemacht werden.
Dies resultierte jedoch nur zwischenzeitlich in einer Zunahme der Nutzung von Java-Versionen ohne LTS: Gegenüber den Versionen mit LTS basieren auf ihnen nur 2,7 % der in der Produktion ausgeführten Anwendungen. Anbieter wie etwa Azul Systems liefern zwar Patches für einige der Versionen ohne LTS aus. Dies ist jedoch eher die Ausnahme, was mit Blick auf diese Versionen auch die geringe Upgrade-Bereitschaft erklären dürfte. So ist Java 14 aktuell die am häufigsten genutzte Version der Programmiersprache ohne LTS. Die Schlusslichter bilden dabei die Versionen 10 und 16.
Popularität von Oracle rückläufig, Amazon holt auf
Prägend für die vergangenen Jahre sind Umwälzungen in der Nutzung der Quellen für Distributionen des Java Developer Kit (JDK). Früher noch auf deutlich breiterer Basis eingesetzt, mussten die JDKs von Oracle im Zuge der Vielzahl an Open-Source-Optionen, die im Rahmen des OpenJDK-Projekt rund um Java verfügbar geworden sind, deutliche Einbußen bei ihrer Nutzergemeinde hinnehmen.
Aus dem nachfolgenden Diagramm ist eine Abkehr von den JDKs von Oracle abzuleiten. Ein Grund hierfür dürfte auch die restriktivere Lizenzierungspolitik rund um seine JDK-11-Distribution sein, die Oracle erst im Zuge von Java 17 wieder durch ein offeneres Modell ersetzte. So war Oracle mit rund 75 % Marktanteil im Jahr 2020 der populärste Anbieter von Java-SDKs. An dieser Position rangiert Oracle zwar weiterhin, doch mit gerade einmal der Hälfte des Anteils von damals. Dagegen konnte etwa Amazon erheblich zulegen: Gegenüber 2,18 % im Jahr 2020 liegt sein Marktanteil nun bei ganzen 22 %.
Neben der Abnahme der Nutzung zugunsten der Zahlen aller anderen Anbieter beobachten wir eine weitere interessante Entwicklung, die sich seit November 2021 herauskristallisiert hat: Eclipse Adoptium und Amazon haben seit der Veröffentlichung von Java 17 ihre Ränge mit nahezu exakt den Nutzungszahlen vertauscht, die der jeweils andere Anbieter zuvor verzeichnete.
Container als allgegenwärtiges Bild
Die Containerisierung von Anwendungen etabliert sich immer weiter zum Standard – ein Trend, der sich auch in unseren Daten zu Java-Anwendungen deutlich widerspiegelt. So entstammen heute 70 % der Daten, die auf Java basierende Anwendungen an New Relic übermitteln, aus einem Container.
Compute-Konfigurationen in Containern
Container beeinflussen die Nutzungsmuster von Rechen- und Speicherressourcen, so etwa im Hinblick auf die Zahl der zugewiesenen Prozessorkerne: Unseren Daten nach nutzt ein erheblich größerer Anteil der Anwendungen, die in Containern ausgeführt werden, weniger als vier Kerne.
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 G1 Garbage Collector: Bei Zuweisung von weniger als zwei Kernen sind diese nicht mehr realisierbar. Denn sämtliche mit nur einem Prozessorkern ausgeführten Instanzen nutzen womöglich auch den seriellen Collector, wofür dann auch die ihm zugehörigen Performance-Kosten anfallen. Vielen ist dies bislang offenbar jedoch noch nicht bewusst.
Speicherkonfigurationen in Containern
Ganz ähnlich zeigen sich die Trends bei der Zuweisung von Speicherressourcen: Containerisierte Anwendungen sind hier tendenziell sparsamer ausgestattet, wobei gemäß unseren Daten nur für 80 % von ihnen anhand der Flags „-Xmx“ oder „-XX:MaxRAMPercentage“ explizit eine Obergrenze des JVM-Speichers definiert ist. Aufgrund der Features rund um Container Awareness, die Java seit Version 9 für virtuelle Maschinen bietet, ist dies jedoch nicht mehr so wie früher ein Problem für die Sicherheit der Anwendung – vorausgesetzt, die JVM ist der einzige in einem Container ausgeführte Prozess.
Garbage Collectors – wer entsorgt den Abfall?
Garbage Collection (GC) bleibt ob seiner zentralen Rolle für die JVM-Performance auch weiterhin ein viel diskutiertes Thema in der Community.
Dabei zeigen unsere Daten: Im Zuge der Veröffentlichung der Folgeversionen von Java 8 haben sich die Nutzungstrends rund um Garbage Collectors deutlich verändert. Unbedingt überraschend ist dies angesichts der Aktualisierungen der Standard-Algorithmen und der gesteigerten Performance, die der seit Java 11 verfügbare G1-Collector bietet, allerdings nicht.
Bei Anwendungen, für die auf Java jenseits von Version 8 gesetzt wurde, ist G1 der klare Favorit. Andere, experimentelle GC-Algorithmen wie ZGC und Shenandoah, die nach Java 8 aus der Taufe gehoben wurden, sind bislang noch weniger von Bedeutung. Dies war jedoch zu erwarten, denn diese gelten erst seit Kurzem als „production-ready“.
Methodik
Die Zahlen in diesem Report wurden allesamt auf Grundlage von Anwendungen ermittelt, die im Januar 2022 Daten an New Relic übermittelt haben. Entsprechend liefern sie kein komplettes Bild der globalen Java-Nutzung. Die Daten wurden anonymisiert und um Details bereinigt, die nicht zur allgemeinen Beurteilung des Java-Ökosystems vonnöten sind. Sämtliche Informationen, die für Cyber-Angriffe oder andere böswillige Aktivitäten von Nutzen sein könnten, haben wir aus diesem Report komplett ausgeklammert.
Über New Relic
Als führender Anbieter von Observability-Technologien unterstützt New Relic die globale Engineering-Community mit einer datenfundierten Methodik für das gesamte Software Lifecycle – von der Konzept-Phase bis zur operativen Umsetzung. In New Relic One erhalten Entwickler:innen die einzige Plattform zur Erfassung sämtlicher Telemetriedaten: Metrics, Events, Logs und Traces. Im Verbund mit umfassenden Analyse-Tools für den gesamten Stack leitet sie New Relic One in kürzester Zeit von einer grundlegenden Situationsanalyse zur genauen Problemursache. Mit dem einzigen klar planbaren verbrauchsbasierten Kostenmodell der Branche setzt New Relic auf absolute Transparenz in jeder Hinsicht und liefert der Engineering-Community so diverse Vorteile: angefangen bei einer effizienteren Cycle-Planung und weniger Ausfallrisiko bei Änderungen über höhere Release-Frequenzen bis hin zu kürzeren Lösungszeiten. Global führende Marken wie AB InBev, Banco International, Chegg, Gojek, Signify Health, TopGolf, World Fuel Services (WFS) und Zalora optimieren so ihre Uptime und Stabilität kontinuierlich und steigern über ihr Kundenerlebnis direkt ihr eigenes Innovationspotenzial und Wachstum.
