JVM開発者の62%が採用、IDE市場を席巻するIntelliJ IDEA
2020年2月5日
0 分で読めます年次JVMエコシステムレポートへようこそ！本レポートでは、JVMエコシステムに関する最大規模の年次調査の結果を紹介します。2019年下半期に2,000件を超える回答が寄せられました。JavaやJVM関連のトピックについて、知見を共有してくださった皆さまに感謝いたします。
本レポートは全6回の記事で構成されています。
JVM開発者の62%が採用、IDE市場を席巻するIntelliJ IDEA
これらすべての情報をまとめた、手作りの素敵なPDFレポートもご用意しています。ダウンロードしてご覧ください。
主に使用している統合開発環境（IDE）は何ですか？
以下のグラフの結果は、最近の他の調査結果とも一致しています。JVMコミュニティで最も広く使われているIDEはIntelliJ IDEAです。今回の調査では、開発者の62%がIntelliJ IDEAのCommunity版またはUltimate版を使用しており、JVM開発者の間で現在最も広く使われているIDEとなっています。
Apache NetBeansは市場シェア20%で3位を維持しており、昨年とほぼ同じ水準です。一方、リストの下位を見ると、VS Codeの採用率が昨年と比べてほとんど伸びていないことに驚かされます。他のエコシステムでは人気のIDEの一つと見なされているにもかかわらず、JVM開発者の間では同じような人気を得ていないようです。
実際、VI/Vim/Emacsの採用率でさえVS Codeを上回っています。この結果から、IDEを好まない開発者層の存在が浮かび上がります。彼らは筋金入りのコーダーなのでしょうか。それとも、すべてを手入力するほうが賢く感じるのでしょうか。いずれにしても、私たちは評価しません！ :)
すぐに使える豊富な機能とKotlinのネイティブサポートが、IntelliJ IDEAの人気上昇に寄与しています。一方、Eclipse IDEは昨年の38%から今年はわずか20%に減少し、IntelliJ IDEAとの差は広がっています。2016年以前はEclipseが最もよく使われていたIDEだったこと（過去のデータにはRebelLabsのレポートを快くご提供いただきました）を踏まえると、JetBrainsがJVM開発者のニーズに合うようソフトウェアを改善してきたことが分かります。
メインアプリケーションで使用しているビルドツールは何ですか？
チームによっては、プロジェクトごとに複数のビルドシステムを使い分けている場合があります。そのためこの質問では、開発者がメインアプリケーションで最もよく使うビルドツールを把握し、過去のデータ（以前のRebelLabsおよびSnykのレポートから引用）と比較して傾向を明らかにするため、回答は1つだけ選択できるようにしました。
Mavenが依然として首位で、シェアは3分の2を占め、昨年からわずかに増加しました。2位のGradleも、競合するMavenと同じ伸び率を示しています。ビルドシステムをめぐる「戦い」は終わったのでしょうか。それとも、ただ休戦中なのでしょうか？
Maven用Snykプラグインを使えば、ビルドのたびにアプリケーションをスキャンし、既知の脆弱性を含む直接依存関係や推移的依存関係を使用していないか確認できます。
使用しているCIサーバーは何ですか？
多くのJava開発者が予想するように、CIサーバーの競争ではJenkinsが圧倒的な58%のシェアで首位に立ちました。Jenkinsと、2番目に多かった「使用していない」との間には大きな差があります。CIサーバーを使わない人の割合は昨年より大幅に減ったものの、依然として驚くほど高い水準です。では、なぜCIサーバーを使わないのでしょうか？今後の調査で開発者に聞いてみたい興味深い質問です。
Jenkinsに次ぐのは、シェア6%のGitLabと5%のTeamCityです。
Jenkins用Snykプラグインを追加すると、CIの実行ごとにアプリケーションの既知の脆弱性を検査できます。これにより、既知の脆弱性を含むコードを誤って本番環境にプッシュするのを防げます。
メインアプリケーションで使用しているコードリポジトリは何ですか？
GitLabがこの競争を制したと聞くと、意外に思う人もいるかもしれません。市場シェアは合計35%で、2位のGitHub（31%）をわずかに上回っています。また、GitLabのパブリック利用率が低いのは、長年にわたってプライベートリポジトリを提供してきたことが主な理由だと考えられます。さらに、GitLabはリポジトリだけでなく、CIパイプラインなど多くの機能を提供しています。ただし、前の質問への回答を考慮すると、GitHubではなくGitLabを使う理由がそれだとは考えにくいでしょう。
GitHubリポジトリにSnykの依存関係スキャンを追加すれば、すべてのプルリクエストをテストし、オープンソースの依存関係に新たな既知の脆弱性や不適切なライセンスが含まれていないか確認できます。
既知の脆弱性がないか、依存関係をいつスキャンしていますか？
依存関係をスキャンして既知の脆弱性を確認することは、何よりも重要です。他の人が作成したコードを安全に使用できるか把握することは欠かせません。脆弱性が発見されると、そのパッケージの利用範囲によって、影響を受ける可能性のある対象は広範囲に及びます。脆弱性がすでに公表されている場合、新しいバージョンでは修正されている可能性が高いでしょう。しかし、開発者が既知のセキュリティ問題や修正の存在を知らずに古いバージョンを使い続けていると、気付かないうちに脆弱な状態に置かれます。
調査によると、回答者の30%がCI/CDパイプラインの一環として、依存関係の既知の脆弱性をスキャンしています。こうしたスキャンを本番環境へのデプロイ前のゲートキーパーとして使うのは、良いスタートです。
ただし、開発中の複数の段階、たとえばローカルマシン上（16%）やPRの公開時（9%）にもスキャンすれば、問題をより早い段階で特定できます。
ソフトウェア開発ライフサイクル（SDLC）の後半で問題が見つかると、修正のために大幅な手戻りが必要になることがよくあります。
そう考えると、回答者のうち本番環境でアプリケーションを監視しているのがわずか8%というのは意外です。脆弱性は時間の経過とともに発見されるため、本番環境のスナップショットを定期的に監視するのが賢明です。さらに驚くべきことに、参加者の28%は依存関係の既知の脆弱性をスキャンしていません。この割合の背景には、現在のアプリケーションで依存関係をまったく使っていないという事情があることを願います。次のEquifaxになりたい人はいませんよね？
レポートはまだまだ続きます！次はどのセクションを読みますか？
JVM開発者の62%が採用、IDE市場を席巻するIntelliJ IDEA