1995 年、Sun Microsystems は Java プログラミング言語をリリースしました。これは、最新のマルチメディア アプリケーションを開発するための、よりポータブルで対話型の方法を提供しました。それ以来、Java は主流のプログラミング言語の 1 つとなり、あらゆる分野で使用されており、「一度書けばどこでも実行できる」という利点があります。
Javaエコシステムの最新の開発状況を明らかにするため、分析会社New Relicはこのほど、新バージョンやコンテナアプリケーション、ガベージコレクションなどの機能を調査した結果、「2023年のJavaエコシステム状況」レポートを発表した。
この記事では、この広く使用されているプログラミング言語についての深い理解を共有します。
Java 17 の採用は 1 年で 430% 増加
ご存知のとおり、Java リリースは長期サポート (LTS) リリースと短期サポート リリースに分かれています。一般に、長期サポートされるバージョンは比較的安定しているか、公式パッチ パッケージが継続的に更新されます。短期サポート リリースは暫定リリースとしてのみ存在します。
オラクルがJava版の更新頻度を6か月に変更した2017年以降、長期サポートLTS版はおよそ2～3年ごとに更新されています。しかし、この更新頻度の高さはネットユーザーから数え切れないほどの苦情を引き起こし、学習できないという声が後を絶たず、多くの人が「変更してもいいし、必要ない」という「悪い」状態を示しています。 」。
いいえ、Oracle は今年 3 月に Java 20 の最新バージョンをリリースしました。しかし、最新のデータレポートによると、Java 11 は 2 年連続でリストのトップとなり、開発者によって最も一般的に使用される Java のバージョンとなっています。
現在、アプリケーションの 56% 以上が実稼働環境で Java 11 を使用しており、2022 年の 48%、2020 年の 11% から増加しています。
Java 8 の使用率もそれほど遅れておらず、アプリケーションのほぼ 33% が本番環境で Java 8 を使用しています (2022 年の 46% から減少)。
Java 11 が 1 位ですが、最新の LTS バージョンである Java 17 の採用率は年々増加しており、昨年は 1% 未満でしたが、今年は 9% 以上になりました。調査レポートによると、Java 17 は過去 1 年間で 430% 成長しましたが、Java 11 はそのレベルに達するまでに何年もかかりました。
これに対し、実稼働環境で Java 7 を使用しているアプリケーションはわずか 0.28% です。これには理由がないわけではありません。その理由は、Java 7 の公式サポートが 2022 年に終了するためです。Java 7 を使用するほとんどのアプリケーションは、アップグレードされていないレガシー アプリケーションです。
短期的な非 LTS Java バージョンの使用率は、LTS バージョンと比較して非常に低いままであり、非 LTS Java バージョンを使用しているアプリケーションはわずか 1.6% (2022 年の 2.7% から減少) です。
レポートの調査結果によると、非 LTS バージョンの使用減少に寄与した可能性のある要因には次のようなものがあります。
サポートの不足
魅力のない新機能
次のLTSリリースまでの時間が短すぎる
かつて、Java 8 がリリースされた後、外部の世界では次の LTS バージョンである Java 11 がいつリリースされるかわかりませんでした。しかしその後、Oracle は明確な約束をしました: 6 か月ごとのアップデート。それ以来、誰もが明確に理解しており、当然のことながら、本番環境で不安定な非 LTS バージョンを使用するよりも、次の LTS バージョンを待ちたいと考えています。
データによると、使用されている非 LTS Java バージョンの中で Java 14 が 0.57 パーセント (2022 年の 0.95 パーセントから低下) で依然として最も人気があり、Java 15 もそれほど遅れていません (0.44 パーセント、2022 年の 0.95 パーセントから低下)。 0.70%）。
Amazon は現在、最も人気のある JDK ベンダーです
近年、使用される Java Developer Kit (JDK) ディストリビューションのソース コードが変更されました。以前は、多くの開発者が Oracle から JDK を入手することがよくありましたが、Oracle JDK はその後、商用アプリケーションに対して課金ポリシーを採用したため、多くの人が意欲を失いました。幸いなことに、OpenJDK プロジェクトはますます充実しており、誰もが選択できるようになりました。
調査データによると、2020 年には Oracle が最も人気のある JDK ベンダーであり、Java 市場の約 75% を占めています。JDK 11 リリースのライセンスが厳しくなった後 (Java 17 がよりオープンな姿勢に戻る前)、業界の開発者は Oracle から離れ始めました。オラクルは2022年も34％のシェアでトップの座を維持するが、2023年には28％に低下するだろう。
まったく対照的に、Amazon の使用率は市場シェアの 31% (2020 年の 2.18%、2022 年の 22%) まで急激に上昇し、最も人気のある JDK ベンダーとなっています。
New Relic の調査によると、コンテナ化されたアプリケーションが主流になり、Java アプリケーションの 70% がコンテナから来ています。
コンテナは、エンジニアリング チームがコンピューティング リソースとメモリ リソースを割り当てる方法に影響を与えます。たとえば、New Relic データでは、4 コア未満のコンテナーで実行されているアプリケーションの割合がはるかに高いことが示されています。
エンジニアリング チームは、コンテナ内のシングルコア セットアップから移行しており、使用しているのはわずか 36% (2022 年の 42% から減少)、マルチコア セットアップに移行しており、29% 以上が 8 コア セットアップを使用しています (20 コアから増加) % (2022 年には)。
エンジニアリング チームは通常、コンテナを頻繁にデプロイするクラウド環境で小規模なコンピューティング セットアップを使用します。ただし、この傾向により、一部のアプリケーションでは予期しない問題が発生し、構成が縮小される可能性があります。たとえば、チームが 1 つの CPU のみを使用している場合、たとえ明示的にガベージ コレクタを設定したとしても、期待するガベージ コレクタを取得できない可能性があります。
自動ガベージ コレクションは、ヒープ メモリを調べ、使用中のオブジェクトと使用されていないオブジェクトを特定し、未使用のオブジェクトを削除するプロセスです。JVM パフォーマンスにおける中心的な役割を考えると、ガベージ コレクションは Java コミュニティで依然としてホットなトピックです。
New Relic のデータによると、Garbage-First (G1) ガベージ コレクターは依然として Java 11 以降を使用するユーザーのお気に入りであり、顧客の 65% がそれを使用しています。G1 の主な利点の 1 つは、一度に大きな領域ではなく小さな領域をクリアすることで収集プロセスを最適化できることです。また、実行がフリーズすることはほとんどなく、若い世代と古い世代の両方を収集できるため、エンジニアにとって適切なデフォルトになります。
Java 8 以降に登場した他の実験的なガベージ コレクター (ZGC および Shenandoah) は、実稼働システムではまだほとんど使用されていません。どちらにも実稼働対応バージョンがありますが、一般的な取り扱いでは依然として無視できます。
完全なレポートについては、https://newrelic.com/sites/default/files/2023-04/new-relic-2023-state-of-the-java-ecosystem-2023-04-20.pdf を参照してください。
