Skip to main content

Spring dominiert das Java-Ökosystem: 60 % nutzen es für ihre Hauptanwendungen

Artikel von
jvm with logos feature

5. Februar 2020

0 Min. Lesezeit

Willkommen zu unserem jährlichen JVM-Ökosystembericht! Dieser Bericht präsentiert die Ergebnisse der größten jährlichen Umfrage zum JVM-Ökosystem. Die Umfrage, an der in der zweiten Hälfte des Jahres 2019 über 2.000 Personen teilnahmen, liefert spannende Einblicke. Wir möchten allen danken, die teilgenommen und ihre Erkenntnisse zu Java und JVM-bezogenen Themen mit uns geteilt haben.

Dieser Bericht ist in sechs Beiträge unterteilt:

  1. JVM-Ökosystembericht 2020 – Einführung

  2. 36 % der Entwickler sind im vergangenen Jahr von Oracle JDK zu einer alternativen OpenJDK-Distribution gewechselt

  3. 64 % der Entwickler geben an, dass Java 8 weiterhin die am häufigsten verwendete Version ist

  4. Kotlin überholt Scala und Clojure und wird zur zweitbeliebtesten Sprache auf der JVM

  5. Spring dominiert das Java-Ökosystem: 60 % nutzen es für ihre Hauptanwendungen

  6. IntelliJ IDEA dominiert den IDE-Markt: 62 % der JVM-Entwickler verwenden die IDE

Außerdem gibt es einen liebevoll gestalteten PDF-Bericht, der all diese Informationen an einem Ort zum Herunterladen enthält.

Verwenden Sie das Spring Framework?

Genau 6 von 10 Personen setzen für den produktiven Einsatz ihrer Anwendung auf das Spring Framework. Das ist ein bemerkenswert hoher Marktanteil für ein Open-Source-Framework eines Drittanbieters.

Piktogramm mit sechs violetten Figuren mit der Beschriftung „Ja“ und vier hellblauen Figuren mit der Beschriftung „Nein“ sowie einem Snyk-Logo

Welche Spring-Version verwenden Sie für Ihre Hauptanwendung?

Spring gibt es schon seit Langem. Durch bedeutende Änderungen und Innovationen hat sich Spring zum dominierenden Framework im Java-Ökosystem entwickelt. Da zwei Drittel der Spring-Nutzer mit Spring 5 arbeiten, werden neuere Versionen schnell angenommen.

Balkendiagramm mit den Nutzungsraten nach Version: 5.1.x 48 %, 5.0.x 18 %, 4.3.x 17 % und weitere Versionen mit jeweils höchstens 5 %.

Welche serverseitigen Web-Frameworks verwenden Sie?

Auf der Serverseite dominiert weiterhin Spring: Die Hälfte des Marktes verwendet Spring Boot und fast ein Drittel Spring MVC.

Frameworks wie Micronaut und Quarkus haben vermutlich das Zeug dazu, mit Spring zu konkurrieren. Warten wir dennoch den Bericht des nächsten Jahres ab, bevor wir Schlussfolgerungen ziehen. JHipster scheint nicht so beliebt zu sein, wie man angesichts der vielen Vorträge auf Konferenzen erwarten würde. Interessant ist auch, dass JSF noch immer lebt.

Horizontales Balkendiagramm: Spring Boot 50 %, Spring MVC 31 %, JSF 11 % und andere Java-Frameworks 3–5 %; 21 % wählten keine davon aus.

Verwenden Sie Enterprise Java? (J2EE, Java EE, Jakarta EE)

Ob Java-Entwickler die Enterprise Edition (EE) von Java verwenden, fragen wir jedes Jahr. In diesem Jahr haben wir die Frage jedoch leicht angepasst. Wir haben die Option „Ja, über Spring oder ein anderes Framework (z. B. JPA oder Servlets)“ hinzugefügt, damit Personen, die EE indirekt verwenden, nicht mit „Nein“ antworten.

35 % der Entwickler geben an, dass sie Java EE nicht verwenden. Damit hat sich die Situation seit dem Vorjahr (38 %) kaum verändert. Wichtig ist jedoch, dass 4 von 10 Entwicklern Enterprise Java indirekt verwenden. Das wirft einige Fragen zur Beliebtheit von Java EE auf.

Ringdiagramm: 24 % verwenden es direkt, 41 % verwenden Spring oder ein anderes Framework und 35 % verwenden es nicht.

Welche Java-EE-Version verwenden Sie für Ihre Hauptanwendung?

Fast 4 von 10 Personen verwenden die neueste Version von Java EE, während Java EE 7 weiterhin recht beliebt ist. Außerdem gaben 2 % der Entwickler an, noch J2EE zu verwenden. Auch wenn dieser Anteil sehr gering erscheint, ist er beachtlich: Er entspricht fast dem Anteil der Personen, die Scala als Hauptsprache für ihre Anwendungen verwenden!

Wichtig ist auch, dass 21 % der Befragten die genaue Version von Java EE, die sie verwenden, nicht kennen. Als wir die Antworten auf diese Frage mit denen der vorherigen Frage verglichen, stellten wir fest, dass 95 % der Entwickler, die ihre genaue Java-EE-Version nicht kennen, Java EE indirekt über das Spring Framework verwenden.

Balkendiagramm mit Java EE 8 bei 37 %, Java EE 7 bei 29 %, Java EE 6 bei 9 %, Java EE 5 und J2EE mit jeweils 2 % sowie 21 %, die sich nicht sicher sind.

Wie haben Sie darauf reagiert, dass Oracle und die Eclipse Foundation sich nicht auf die weitere Verwendung des javax-Namespace einigen konnten?

Nach monatelangen Verhandlungen konnten Oracle und die Eclipse Foundation keine Einigung über die Verwendung des javax-Package-Namespace durch die Eclipse Foundation Community erzielen. Der javax-Namespace ist eine Marke von Oracle. Das bedeutet, dass alle künftigen Verbesserungen an Jakarta EE durch die Eclipse Foundation einen anderen Paketnamen verwenden müssen. Änderungen an Jakarta EE gehen daher auch mit der Migration von Bibliothekscode einher.

Die Änderung des Paketnamens macht zwar eindeutig kenntlich, wem das Paket gehört – Oracle bis Java EE 8 und der Eclipse Foundation ab Jakarta EE 8 –, betrifft jedoch jede API der Enterprise Edition, da sie alle mit javax beginnen.

Auf die Frage nach dieser Entwicklung reagierte die große Mehrheit der Teilnehmenden verärgert über Oracles Haltung. 2 von 3 JVM-Entwicklern äußerten sich enttäuscht über die ausgehandelten Ergebnisse. Tatsächlich werfen die Antworten auf diese Frage einige Fragen zu Oracle auf. Was wäre, wenn dieses Ergebnis letztlich Oracles Verantwortung für Java schadet?

Umfragegrafik mit den Reaktionen: 37 % sehr enttäuscht, 32 % ein wenig verärgert, 17 % finden es in Ordnung, 2 % sind zufrieden und 14 % sind unsicher.

Würden Sie einen Wechsel zu einem anderen Framework oder einer anderen Technologie in Betracht ziehen, um aufgrund der Änderungen am javax-Namespace nicht auf eine neuere Jakarta-EE-Version migrieren zu müssen?

Obwohl die Mehrheit der Befragten von den Änderungen am javax-Namespace eher enttäuscht ist, würde nur 1 von 10 Entwicklern zu einem anderen Framework wechseln. Laut unserer Umfrage bleiben 66 % der Entwickler wahrscheinlich oder definitiv bei Jakarta EE, trotz der Änderungen am Namespace. Möglicherweise glauben Entwickler, dass diese Änderungen sie nicht betreffen, da die Mehrheit EE indirekt über Frameworks wie Spring verwendet. Das deutet darauf hin, dass die Änderung des Namespace eher eine enttäuschende Unannehmlichkeit darstellt als etwas, das Entwickler tatsächlich zum Handeln bewegt.

Ringdiagramm mit den Antworten: 10 % definitiv ja, 24 % wahrscheinlich, 36 % unwahrscheinlich und 30 % nein – Jakarta EE ist die klare Wahl.

Welche anderen Sprachen verwendet Ihre Anwendung?

Nur noch wenige Menschen verwenden für ihre Anwendungen eine einzige Sprache. Man kann mit Fug und Recht sagen, dass die große Mehrheit der Entwickler heute mehrsprachig, Full-Stack- oder polyglott arbeiten muss. Da Sprachen oft einem bestimmten Zweck dienen, ist es naheliegend, dass Entwickler neben ihrer Hauptsprache auf der JVM weitere Sprachen verwenden. Das bedeutet nicht, dass Ihnen diese Sprachen gefallen müssen. Manche Sprachen gelten als notwendiges Übel, wenn sie für einen bestimmten Zweck gebraucht werden.

Wichtig ist, dass bei dieser Frage mehrere Antworten möglich waren. Die Ergebnisse sind jedoch keine große Überraschung. JavaScript ist mit 62 % die beliebteste Sprache für die Frontend-Entwicklung, SQL ist mit 44 % die beliebteste Sprache für Datenbankabfragen, und für Data-Science- und Machine-Learning-Anwendungen ist Python mit 22 % am beliebtesten.

Horizontales Balkendiagramm mit Frontend-JavaScript (62 %) und SQL (44 %) als den am häufigsten genannten Technologien, gefolgt von Python und Node.js (jeweils 22 %).

Welche clientseitigen Web-Frameworks verwenden Sie?

Bei dieser Frage konnten die Teilnehmenden mehrere Optionen auswählen – warum sich für ein Framework entscheiden, wenn man sie alle verwenden kann?

Den Antworten zufolge liegt Angular mit 38 % klar vorn. Da es jedoch so viele Angular-Versionen gibt, wissen wir nicht genau, ob hier neuere oder ältere Versionen die Nase vorn haben. React liegt mit 31 % auf dem zweiten Platz, dicht gefolgt von jQuery mit 28 %.

Interessant ist auch, dass laut unserer Umfrage 2 von 10 Entwicklern überhaupt keine Frameworks verwenden. Mal sehen, ob sich diese Liste im Laufe der Zeit deutlich verändert.

Horizontales Balkendiagramm mit Angular 38 %, React 31 %, jQuery 28 %, Keine 20 %, Vue 11 % und Backbone 2 %; Mehrfachantworten waren möglich.

Dieser Bericht hat noch mehr zu bieten! Welchen Abschnitt möchten Sie als Nächstes lesen?

  1. JVM-Ökosystembericht 2020 – Einführung

  2. 36 % der Entwickler sind im vergangenen Jahr von Oracle JDK zu einer alternativen OpenJDK-Distribution gewechselt

  3. 64 % der Entwickler geben an, dass Java 8 weiterhin die am häufigsten verwendete Version ist

  4. Kotlin überholt Scala und Clojure und wird zur zweitbeliebtesten Sprache auf der JVM

  5. Spring dominiert das Java-Ökosystem: 60 % nutzen es für ihre Hauptanwendungen

  6. IntelliJ IDEA dominiert den IDE-Markt: 62 % der JVM-Entwickler verwenden die IDE

Laden Sie den Bericht jetzt herunter!

Weiterlesen

Blog

Frontier-Modelle fanden die Schwachstellen. Nur der Angreifer fand die Angriffsketten.

Die statische Analyse fand die Schwachstellen, doch erst Live-Angriffstests bewiesen, wie sie sich zu Angriffen verketten lassen. Ein Vergleich von Evo COS, Claude Security und Claude Code Security.

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.

Blog

Warum KI-Coding-Agenten immer wieder fehlerhafte Zugriffskontrollen schreiben

KI-Coding-Agenten können Autorisierungslogik erzeugen, die kompiliert und die Prüfung besteht, dabei aber die Daten eines Mandanten für einen anderen offenlegt. Erfahren Sie, warum fehlerhafte Zugriffskontrollen schwer zu erkennen sind und wie Sie sie verhindern.