IntelliJ IDEA dominiert den IDE-Markt: 62 % nutzen die Entwicklungsumgebung
5. Februar 2020
0 Min. LesezeitWillkommen zu unserem jährlichen JVM-Ökosystem-Bericht! Dieser Bericht präsentiert die Ergebnisse der größten jährlichen Umfrage zum JVM-Ökosystem. Er zeigt die Ergebnisse einer Umfrage, an der in der zweiten Jahreshälfte 2019 über 2.000 Personen teilgenommen haben. Wir möchten uns bei allen bedanken, die mitgemacht und ihre Einblicke zu Java und Themen rund um die JVM mit uns geteilt haben.
Dieser Bericht besteht aus sechs Beiträgen:
64 % der Entwickler geben an, dass Java 8 weiterhin die am häufigsten verwendete Version ist
Kotlin überholt Scala und Clojure und wird zur zweitbeliebtesten Sprache auf der JVM
Spring dominiert das Java-Ökosystem: 60 % verwenden es für ihre Hauptanwendungen
IntelliJ IDEA dominiert den IDE-Markt: 62 % der JVM-Entwickler nutzen es
Außerdem gibt es einen liebevoll gestalteten PDF-Bericht, der all diese Informationen an einem Ort zum Herunterladen enthält.
Welche integrierte Entwicklungsumgebung (IDE) verwenden Sie hauptsächlich?
Die Ergebnisse in der Grafik unten stimmen mit denen anderer aktueller Umfragen überein: IntelliJ IDEA ist die am weitesten verbreitete IDE in der JVM-Community. Laut unserer Umfrage verwenden 62 % der Entwickler die Community- und Ultimate-Versionen von IntelliJ IDEA. Damit ist sie heute die dominierende IDE unter JVM-Entwicklern.
Apache NetBeans behauptet sich mit 20 % Marktanteil auf dem dritten Platz – ungefähr genauso viel wie im Vorjahr. Weiter unten in der Liste fällt jedoch auf, dass die Nutzung von VS Code im Vergleich zum Vorjahr kaum zugenommen hat. Obwohl VS Code in anderen Ökosystemen zu den bevorzugten IDEs zählt, scheint es bei JVM-Entwicklern nicht ebenso beliebt zu sein.
Tatsächlich ist die Nutzung von VI/Vim/Emacs sogar weiter verbreitet als die von VS Code. Diese Ergebnisse machen eine Gruppe von Entwicklern sichtbar, die offenbar keine IDEs mögen. Sind das echte eingefleischte Programmierer oder fühlen sie sich schlauer, wenn sie alles von Hand eingeben? Wie dem auch sei: Wir urteilen nicht! :)
Die Vielzahl an sofort verfügbaren Funktionen und die native Kotlin-Unterstützung haben zur wachsenden Beliebtheit von IntelliJ IDEA beigetragen. Der Anteil der Eclipse IDE ist von 38 % im Vorjahr auf nur noch 20 % in diesem Jahr gesunken, wodurch der Abstand zu IntelliJ IDEA weiter wächst. Vor 2016 war Eclipse laut den freundlicherweise von RebelLabs bereitgestellten Ergebnissen die meistgenutzte IDE. Daran wird deutlich, dass JetBrains gute Arbeit geleistet hat, die Software an die Anforderungen von JVM-Entwicklern anzupassen.
Welches Build-Tool verwenden Sie für Ihre Hauptanwendung?
Teams sind möglicherweise bei verschiedenen Projekten auf mehrere Build-Systeme angewiesen. Deshalb haben wir für diese Frage nur eine Antwort zugelassen: Wir wollten herausfinden, welches Build-Tool Entwickler am häufigsten für ihre Hauptanwendung verwenden, und es mit früheren Daten vergleichen (ebenfalls aus früheren Berichten von RebelLabs und Snyk), um Trends sichtbar zu machen.
Maven liegt mit zwei Dritteln Marktanteil weiterhin an der Spitze und konnte seit dem Vorjahr leicht zulegen. Gradle, der Zweitplatzierte, wächst genauso schnell wie sein Konkurrent Maven. Ist der „Krieg“ zwischen den Build-Systemen also vorbei, oder machen wir nur eine Pause?
Mit dem Maven-Plugin von Snyk können Sie Ihre Anwendung bei jedem Build scannen und sicherstellen, dass Sie keine direkten oder transitiven Abhängigkeiten mit bekannten Sicherheitslücken verwenden.
Welchen CI-Server verwenden Sie?
Wie die meisten Java-Entwickler erwarten würden, liegt Jenkins mit einem beachtlichen Marktanteil von 58 % beim Rennen um den CI-Server vorn. Zwischen Jenkins und der zweithäufigsten Antwort, „keiner“, klafft eine große Lücke. Zwar nutzen deutlich weniger Personen als im Vorjahr überhaupt keinen CI-Server, doch der Anteil ist immer noch überraschend hoch. Warum entscheiden sich manche gegen CI-Server? Das ist eine interessante Frage für Entwickler in künftigen Umfragen!
Die nächsten Wettbewerber von Jenkins sind GitLab mit 6 % und TeamCity mit 5 %.
Sie können Ihre Anwendung bei jedem CI-Durchlauf auf bekannte Sicherheitslücken testen, indem Sie das Snyk-Plugin für Jenkins hinzufügen. So verhindern Sie, dass Sie versehentlich Code mit bekannten Sicherheitslücken in die Produktion übertragen.
Welches Code-Repository verwenden Sie für Ihre Hauptanwendung?
Vielleicht überrascht es, dass GitLab diesen Wettstreit gewinnt. Mit insgesamt 35 % Marktanteil liegt GitLab knapp vor GitHub auf dem zweiten Platz mit 31 %. Außerdem fällt auf, dass GitLab seltener öffentlich genutzt wird – vor allem, weil das Unternehmen schon lange private Repositories anbietet. Darüber hinaus bietet GitLab mehr als nur ein Repository, darunter auch eine CI-Pipeline. Angesichts der Antworten auf die vorherige Frage ist es jedoch unwahrscheinlich, dass dies der Grund dafür ist, GitLab statt GitHub zu verwenden.
Sie können das Dependency-Scanning von Snyk zu Ihrem GitHub-Repository hinzufügen, damit jeder Pull Request darauf geprüft wird, ob Ihre Open-Source-Abhängigkeiten neue bekannte Sicherheitslücken oder problematische Lizenzen enthalten.
Wann scannen Sie Ihre Abhängigkeiten auf bekannte Sicherheitslücken?
Ihre Abhängigkeiten auf bekannte Sicherheitslücken zu scannen, ist die klügste Entscheidung! Es ist entscheidend zu wissen, ob der von anderen entwickelte Code sicher verwendet werden kann. Wird eine Sicherheitslücke entdeckt, gibt es je nach Verbreitung des jeweiligen Pakets zahlreiche potenziell Betroffene. Ist eine Sicherheitslücke bereits offengelegt, ist wahrscheinlich in einer neueren Paketversion bereits eine Lösung verfügbar. Verwendet ein Entwickler jedoch weiterhin eine ältere Version, ohne von der Sicherheitslücke oder der Lösung zu wissen, ist er gefährdet, ohne es zu bemerken.
Laut unserer Umfrage scannen 30 % der Befragten ihre Abhängigkeiten im Rahmen der CI/CD-Pipeline auf bekannte Sicherheitslücken. Diese Scans als Kontrollinstanz vor der Bereitstellung in der Produktion einzusetzen, ist ein guter Anfang.
Probleme lassen sich jedoch früher erkennen, wenn während der Entwicklung an mehreren Stellen gescannt wird – zum Beispiel auf dem lokalen Rechner (16 %) oder beim Erstellen eines PR (9 %).
Werden Probleme erst später im Softwareentwicklungslebenszyklus (SDLC) entdeckt, ist häufig ein erheblicher Nachbearbeitungsaufwand nötig, um sie zu beheben.
Dennoch ist es überraschend, dass nur 8 % der Befragten ihre Anwendungen in der Produktion überwachen. Sicherheitslücken werden mit der Zeit entdeckt. Deshalb ist es ratsam, regelmäßig einen Snapshot der Produktionsumgebung zu überwachen. Noch beunruhigender ist, dass 28 % der Teilnehmenden ihre Abhängigkeiten nicht auf bekannte Sicherheitslücken scannen. Hoffentlich liegt das daran, dass diese Entwickler in ihrer aktuellen Anwendung gar keine Abhängigkeiten verwenden. Niemand möchte schließlich das nächste Equifax sein, oder?
Dieser Bericht hat noch mehr zu bieten! Welchen Abschnitt möchten Sie als Nächstes lesen?
64 % der Entwickler geben an, dass Java 8 weiterhin die am häufigsten verwendete Version ist
Kotlin überholt Scala und Clojure und wird zur zweitbeliebtesten Sprache auf der JVM
Spring dominiert das Java-Ökosystem: 60 % verwenden es für ihre Hauptanwendungen
IntelliJ IDEA dominiert den IDE-Markt: 62 % der JVM-Entwickler nutzen es