2022年 Javaエコシステムレポート

概要

現代のソフトウェア産業は非常に大きく、プログラミング言語の選択には事欠きません。Javaはプラットフォームに依存せず、コンピュータシステム間で簡単に移動でき、何千ものライブラリが提供され、サポートも充実しているためソフトウェア開発者に絶大な人気を誇り、ほとんどすべての主要産業や経済分野で使用されています。

2020年3月、New Relicはパフォーマンスデータを提供する何百万ものアプリケーションから収集したデータを基に、最初の Javaエコシステムレポート を発行しました。Java 11以降初めての長期サポート（LTS）リリースとなる最近のJava 17のリリースは、そのデータを改めて見直す機会を提供します。本レポートの作成に当たり、New Relicは適切なデータを匿名化し、意図的に粗視化することで、Javaエコシステムの一般的な概要を提供します。第三者やその他の悪用される可能性のある詳細情報は、意図的にレポートから除外しています。

本レポートの目的は、今日のJavaエコシステムの現状について、コンテキストと知見を提供することです。レポートでは、以下のカテゴリーについて検討しました。

• 実運用で最も使用されているバージョン
• 最も人気のあるベンダー
• コンテナの台頭
• 最も一般的なヒープサイズ設定
• 最もよく使われるガベージコレクションアルゴリズム

新しい標準としての Java11

2020年、Java 11が提供されて1年以上が経過しているにもかかわらず、大多数のアプリケーション（84.48%）はJava 8のままでした。それ以来、この2つのLTSリリースバージョンの間でバランスが変化しています。現在、48%以上のアプリケーションが実運用でJava 11を使用しており（2020年の11.11%から増加）、Java 8は僅差で2位、実運用でそのバージョンを使用しているアプリケーションの46.45%を獲得しています。
Java 17は、チャートこそ上昇していませんが、リリースからわずか数カ月で、すでにJava 6、Java 10、Java 16のリリースを上回っています。

Java 7のサポートは2022年に終了しますが、まだ1.71%のアプリケーションが実運用でJava 7を使用しています。一方、Java 6のサポートが終了していますが、0.27%のアプリケーションで使用されています。Java 6やJava 7を使用しているアプリケーションのほとんどは、アップグレードされていないレガシーアプリケーションです。

Java 14は、非LTSバージョンで最も普及しています

Java 9から、プラットフォームのリリースパターンが変更されました。Javaは半年ごとに新しいバージョンが発売されましたが、それらは次のリリースまでしかサポートされません。新しい機能をより頻繁に利用できるようにする目的がありました。

しかし、暫定的な非LTSバージョンのJavaの利用は、実運用中の LTSバージョンと比較して非常に低く、非LTSバージョンの Javaを使用しているアプリケーションはわずか2.7%に過ぎません。Azul Systemsのように、一部の非LTSバージョンでパッチを出荷しているベンダーもありますが、ほとんどのベンダーはそうではありません。そのため、アップグレードに消極的なのだと思われます。使用されている非LTSのJavaバージョンの中で、最も利用されているのはJava 14で、最も利用頻度が低いのがJava 10とJava 16です。

オラクル人気は縮小し、アマゾンが台頭

近年、利用されているJava Developer Kit（JDK）ディストリビューションのソースが変化しています。かつて多くの開発者がオラクルからJDKを入手していたのに対し、OpenJDKプロジェクトでJavaがオープンソース化されたことで、豊富な選択肢が生まれました。

次の表は、オラクルのJDK 11ディストリビューションのライセンスがより制限されるようになってからの（Java 17でよりオープンなスタンスに戻る前）オラクルのバイナリから離れる動きを示しています。2020年には、オラクルが最も人気のあるベンダーで、Java市場のおよそ75%を占めていました。首位は維持しましたが、シェアは半減しています。アマゾンは22%（2020年の2.18%から上昇）と劇的に上昇しました。

2021年11月以降、この数字には、一般的なオラクル離れの動き以外にも、興味深い変化が見られるようになりました。Java 17のリリース以前、Eclipse Adoptiumとアマゾンは、このリストでほぼ同じ反対側に位置していました。

周囲のものすべてを実行するコンテナ

アプリケーションのコンテナ化は極めて主流になっており、New RelicのJavaアプリケーションのデータもこの傾向を裏付けています。New RelicにレポートするJavaアプリケーションの70%以上が、コンテナからレポートしています。

コンテナでの計算設定

コンテナは、計算とメモリのリソースを割り当てる方法に影響を与えています。例えば、New Relicのデータは、コンテナに入れた場合、4コア未満で実行するアプリケーションの割合が非常に高いことを示しています。

コンテナをデプロイすることが多いクラウド環境では、より小さいサイズで実行させることは非常に理にかなっています。しかし、この傾向は、アプリケーションによっては思わぬ問題を引き起こす可能性があります。特に、最近のJava仮想マシン（JVM）のデフォルトのG1ガベージコレクターによる同時実行のメリットの多くは、2コア未満で実行すると消滅してしまいます。これらのシングルコアのインスタンスはすべて、シリアルコレクターを使用しており、そのパフォーマンスコストを支払っているかもしれませんが、おそらく多くの人はそれに気づいていないでしょう。

コンテナでのメモリ設定

メモリ設定の比較でも同様の傾向が見られ、コンテナ内のインスタンスが小さくなる傾向が見られます。New Relic のデータは、コンテナ化されたアプリケーションのうち、-Xmxまたは -XX:MaxRAMPercentageフラグによって JVM メモリの上限を明示的に要求しているのは約80%に過ぎないことを示しています。　　JVMのコンテナ認識機能は、バージョン9以降、JVMが各コンテナで実行される唯一のプロセスである限り、これはおそらく、これらのアプリケーションにとって、以前のような安全性の問題ではないことを意味します。

ガベージイン・ガベージアウト

JVMのパフォーマンスにおいて中心的な役割を果たすガベージコレクション（GC）は、依然としてコミュニティで多くの議論を呼んでいます

New Relicのデータでは、Java 8以降ガベージコレクターの使用状況に明確な変化を示しています。これは、Java 11以降でG1コレクターのデフォルトが更新され、より高いパフォーマンスが得られることを考えれば驚くべきことではありません。

G1は、明らかにJava 8から離れた人たちに好まれています。Java 8以降に登場した他の実験的なコレクター（ZGCとShenandoah）は、実運用システムでの使用は多くありませんが、どちらも最近まで生産可能な状態に達していなかったため、これは予測されることです。

方法論

本レポートのデータは、2022年1月にNew Relicにレポートしたアプリケーションのみから抽出したものであり、Javaの使用状況の全体像を示すものではありません。New Relicは、適切なデータを匿名化し、意図的に粗視化することで、Javaエコシステムの一般的な概要を提供します。第三者やその他の悪用される可能性のある詳細情報は、意図的にレポートから除外しています。

New Relicについて

New Relicは、オブザーバビリティのリーダーとして、優れたソフトウェアの計画、構築、デプロイ、実行に対するデータ駆動型のアプローチでエンジニアを支援しています。New Relic オブザーバビリティ プラットフォームは、エンジニアがすべての遠隔測定（メトリクス、イベント、ログ、トレース）を取得できる唯一の統合データプラットフォームを提供し、最も強力なフルスタック分析ツールとの組み合わせにより、エンジニアが「何か」を超えて「なぜ」を明らかにできるよう支援します。New Relic は、直感的で予測可能な業界唯一の使用ベース価格によって提供され、計画サイクルタイムの改善、変更失敗率の低減、リリース頻度の加速、解決までの平均時間の短縮を支援することにより、エンジニアに高い費用対効果をもたらします。これにより、AB InBev、Banco Internacional、Chegg、Gojek、Signify Health、TopGolf、World Fuel Services（WFS）、Zaloraなどの世界有数のブランドが稼働時間と信頼性を向上し、運用効率を高め、革新と成長を促す優れた顧客体験を提供できるようになりました。