The State of Java: Trends And Data For One of the World’s Most Popular Programming Languagesの意訳記事です。

現代のソフトウェア産業は広大で、プログラミング言語の選択肢には事欠かきません。しかし、Javaエコシステムのような単一の技術スタックであっても、その市場について有益な結論を出すのは難しいことがあります。Javaは信じられないほどの成功を収めており、ほぼすべての主要な産業や経済部門で利用されていますが、このことがJavaエコシステムの状態について一つの断定的な視点を持つことを困難にしている部分もあります。

しかし、だからといって、世界の状況を評価できないわけではありません。

毎日、何千万ものJava仮想マシン（JVM）がNew Relicとデータを共有しています。このレポートを作成するにあたり、我々が見ているJavaエコシステムの大まかな概要を示すために、データを匿名化し、意図的に粗くしています。また、攻撃者やその他の悪意のある当事者に役立つ可能性のある詳細な情報は避けています。

これらの知見が、今日のJavaエコシステムの状態についての新しい文脈と洞察を提供することを願っています。そう言う訳で、私たちは次の疑問に目を向けました。

・本番環境で使用されているJavaのバージョンはどれか

・最も人気のあるベンダーはどこか

・最もよく使われているガベージコレクション・アルゴリズムは何か

・最も一般的なヒープサイズの設定はいくつか

今のところ、Java 8がまだ標準です。

Java開発者がいつも気になっている質問から始めましょう。本番環境で最もよく使われているバージョンはどれでしょうか。次の表をご覧下さい。

注：Java 8は3つに分類しています

Current: 最近更新され、最近のメジャーな CVE に対して脆弱性がないもの

Lagging: Javaバージョンの老化に寄与する潜在的な重大リスクを持っている

Vulnerable: 利用しているチームにとっては深刻な懸念材料になる可能性がある

ご覧のように、長期サポート・リリースであるJava 11の人気は徐々に高まっているが、Java 8（LTS）と比較すると、市場はまだ躊躇しているようです。また、非LTSリリースが不採用だということも見られました。Java 7は、Java 8以降の非LTSの合計（1.14%）の2倍以上の使用率（2.54%）があるとわかりました。

Oracle以外のベンダーの台頭

この1年間に観察されたもう1つの大きな動きは、コミュニティでOracle以外のJavaベンダーが受け入れられるようになってきたことです。

Oracleは現在、Java市場の75%しか占めていません。コミュニティ主導のAdoptOpenJDKは、2番目に人気のあるベンダーとなっています。当社の過去のトレンドデータ（メインデータセットよりもかなり小さいサンプルサイズに基づいているため、公表していません）によると、AdoptOpenJDKの人気は前月比で大幅に上昇しています。

特に注目すべき点は、New Relicで収集している情報によると、AdoptOpenJDK VM全体のうち、ほぼ3分の1（33.19%）がJava 11であることです。これは、AdoptOpenJDKユーザーの間でJava 11の使用率がそれ以外のベンダーよりもはるかに高いことを示しています。

注: 完全な情報開示のため、New RelicはAdoptOpenJDKプロジェクトのスポンサーであり、そのプロジェクトにエンジニアリングとして貢献を行なっています。

ガベージコレクションアルゴリズムの仕組み

メモリ管理で果たす役割において、ガベージコレクションはJavaコミュニティでは限りない関心を集めています。我々のデータによると、様々なガベージコレクションアルゴリズムは以下のような市場シェアを持っています。

大まかに言うと、異なるJavaバージョンで使用されているデフォルトのコレクタが反映された結果となっています。しかし、JVMのバージョン別に見てみると、興味深い結果がいくつか出てきます。

• Java 8 では、CMS は G1 よりも人気がある（56% vs. 12.59%）。
• Java 11ではParallelよりもCMSの方が人気が高い（96% vs. 0.20
• CMSはJava 11でZGCの35倍以上の人気を誇る

ヒープ設定の確認

Javaにおけるガベージコレクションとメモリ管理の議論は、ヒープサイズの設定を見なければ意味がありません。ヒープサイズの設定は、ヒープの最小値と最大値（一般的にはXmsとXmxと呼ばれています）のペアによって定義されます。次の表は、私たちのデータに基づいて、最も一般的なヒープ・サイズのトップ30をリストアップしたものです。理解を容易にするためにMBに正規化しています。

驚くべきことに、JVMのヒープサイズが比較的小さいままであることを示しています。より大きなヒープに対するアルゴリズムを作ろうとしていることとは対照的なように見受けられます。特に、16GB以上になる可能性のあるヒープ（つまり、Xmx >= 16GBの設定）は全体の3.3%に過ぎません。XmsとXmxが同じ値を持つ「固定ヒープ」フラグの組み合わせが継続して出現していることも、大きな驚きでした。私たちのデータによると、33.48%のJVMがいまだにこの組み合わせで実行されています。

適応型サイジングアルゴリズムの非常に初期のバージョンでは、この組み合わせで実行することに何らかの利点があったかもしれませんが、現代のワークロードでは、ほとんどの場合、逆効果です。この組み合わせを設定すると、JVMはヒープのサイズ変更と形状変更の方法に制約を受け、トラフィックの挙動やリクエストレートの急激な変化への応答性が低下します。

この組み合わせがランタイムに存在する場合、ガベージコレクションのパフォーマンスを向上させるためにこの組み合わせを削除できるかどうかを確認するために、いくつかのテストを実行することをお勧めします。

その他興味深いもの

最後に、私たちが観察した5つの興味深い統計を紹介します。

1. Java 8 JVMの7.35%が非推奨フラグ(特にMaxPermSize)を使用して実行している。
2. 全JVMの6.78%が実験的フラグを有効にして実行している。
3. 8.07%のJVMでは、起動文字列に複数回同じフラグを設定している。
4. 2.54%のJVMには、矛盾した「不一致フラグ」がある。例えばParallel GCとG１G Cを指定しているようなもの。
5. 2.59%のJVMは、最大ヒープサイズを819MBに設定しています。これは、ほぼ間違いなく8192MB(すなわち、8GB)のタイポです。カットアンドペーストした設定は危険なので、慎重に設定をチェックしてください。

最後に

私たちのデータは、もちろん完璧ではありません。このレポートの主なバイアスは、New Relicに報告されたデータのみを見たということです。これは決してJava市場を完全に正確に表現したものではなく、当社のデータには選択性やその他の目立たないバイアスがあることを認識しています。

さらに、局所的な傾向によって、我々が提示した内容とはかなりの小規模な差異が生じる可能性があることも認識しています。例えば、特定の業界（ヘルスケアや金融サービスなど）のJavaチームは、一般的に厳格な規制の下で運営されているため、タイムリーにバージョン間を移動することができません。

しかし、私たちは毎日何百万ものJVMからリアルタイムのデータを見ており、刻々と変化するデータの流れが、Java市場全体を代わりに映し出しています。

私たちは、Javaコミュニティにこれらの数字を提示していますが、これは、Java全体の軌道についての魅力的な進行中の議論に前向きな形で貢献することを願っています。「我々がすべての答えを持っている」と主張したり、他の人の仕事を軽蔑したりすることを意図しているわけではありません。これは断固として共有されるべき遍歴であり、RedMonkが最近行った分析のような異なる方法論を組み合わせることで、誰もがより良い全体的な理解を得ることができるでしょう。

New Relicをご利用のお客様は誰でも、本番環境のこのレベルの詳細情報を追加費用なしで利用することができます。New Relicをお使いのお客様（またはお使いになりたいとお考えのお客様）で、このようなインサイトをご覧になりたい場合は、New Relicの担当者に連絡して、このデータを照会する方法や、データを追跡するための独自のダッシュボードを作成する方法をご確認ください。

お客様がより完璧なソフトウェアを生産するための道を歩み続ける中で、お客様のシステムをお客様の条件に合わせて観察するためのお手伝いをさせていただきます。

サーバーレス開発においてJavaがどのように機能しているか興味がありますか？私たちのレポート「For the Love of Serverless: 2020 AWS Lambda Benchmark Report for Developers, DevOps, and Decision Makers.(英語)」をチェックしてみてください。