Java InfoQ トレンドレポート — 2021年12月

いいね

原文(投稿日:2022年01月07日)へのリンク

この記事では、InfoQ Java 編集チームが現在、Java の分野でテクノロジーの採用と新たなトレンドをどのように見ているかについてまとめます。

言語の Java だけでなく、Kotlin や Scala、Java 仮想マシン (JVM)、Java ベースのフレームワークやユーティリティなどの関連言語にも焦点を当てています。

新バージョンの Java の採用のようなコアの Java のトレンドと Jakarta EE、Quarkus、Micronaut、Helidon、MicroProfile や MicroStream などのフレームワークの進化についても話し合っています。

このレポートには2つの主な目標があります:

• 技術リーダが中長期的な技術投資の決定を下すのを支援すること。
• 個々の開発者が、学習とスキル開発のために貴重な時間とリソースをどこに投資すれば良いのかを支援すること。

Java トレンドレポートの発行は今回が3回目です。ただし、2006年から Java と JVM のトレンドを内部で追跡しているため、このトピックは十分にカバーされたニュースを受け取っています。

InfoQ と QCon で現在および将来のトレンドをナビゲートするために、Geoffrey Moore 氏が同名の本で開拓したテクノロジーの成功のための「crossing the chasm (キャズム)」メンタルモデルを利用します。私たちは、Moore 氏が初期市場と呼んでいたものに適合するアイデアを特定しようとしています。「顧客ベースは、機会または迫り来る問題のいずれかを先取りしようとしているテクノロジー愛好家や先見の明のある人々で構成されています」。

2020年と2019年の Java トレンドレポートで行ったように、2021年の内部トピックグラフを示します:

コンテキストとして、2020年の内部トピックグラフを次に示します

イノベーター分野に特定されたいくつかの新しいテクノロジーの他に、注目すべき変更が含まれています。別のカテゴリにある Spring (およびそれらに関連するプロジェクト)、Jakarta EE、Scala のバージョンの定義です。さまざまな成熟度と採用 (adoption) が存在する場合に、これらのテクノロジーを1つのカテゴリーに一般化することを避けるために、このアプローチに決めました。

2022年後半の GA リリースが予定されている Spring Framework 6 と Spring Boot 3 は、モジュールの採用と JDK 17 以降と Jakarta EE 9 を必須とするためのオーバーホールが行われています。Spring Framework 6 の最初のマイルストーンリリースにより最近プレビューが利用可能になりました。

2021年初めに導入された Spring Native は、Java や Kotlin で作成された既存の Spring Boot アプリケーションを GraalVM ネイティブイメージに変換するための新しいツールです。これは開発のかなり初期段階にあります。

今年初めにリリースされた Scala 3 は、多くの新機能、新しい構文、そして何年にもわたって開発されてきた待望の新しい Dotty コンパイラでオーバーホールされました。

今年初め、Microsoft は、OpenJDK の独自のダウンストリームディストリビューションの Microsoft Build of OpenJDK を公開して Java プログラミング言語への取り組みをさらに進めました。

AdoptOpenJDK は Eclipse Foundation に参加してすぐに Adoptium に名称変更されました。Adoptium への移行には、Eclipse Working Group の設立と、Adoptium トップレベルプロジェクトの下で AdoptOpenJDK を複数のサブプロジェクトに分割することが含まれていました。Eclipse AQAvit、Eclipse Temurin、および Eclipse Temurin Compliance です。

ここからは、何人かの InfoQ Java Queue エディタと Java チャンピオンの中でのさまざまなトピックのディスカッションを簡単に編集した要約です:

• Michael Redlich 氏、ExxonMobil Research & Engineering のシニアリサーチテクニシャンであり、InfoQ の Java Queue リードエディター
• Ben Evans 氏、Red Hat のシニアプリンシパルソフトウェアエンジニアであり、Java チャンピオンおよび InfoQ の Java Queue エディター
• Erik Costlow 氏、Contrast Security の開発者リレーションズディレクターであり、InfoQ の Java Queue エディター
• Johan Janssen 氏、Sanoma Learning のソフトウェアアーキテクトであり、InfoQ の Java Queue エディター
• Karsten Silz 氏、シニアフルスタック Java 開発者であり、InfoQ の Java Queue エディター
• Monica Beckwith 氏、Microsoft のシニアプリンシパルエンジニアであり、Java チャンピオン
• Ana Maria Mihalceanu 氏、Red Hat の開発者アドボケイトであり、Java チャンピオン
• Reza Rahman 氏、Microsoft で Azure の Java のプリンシパルプログラムマネージャ
• Simon Ritter 氏、Azul の副 CTO であり、Java チャンピオン

これにより、内部トピックグラフでの一部のテクノロジーの推奨される位置付けについて、より多くのコンテキストが提供されると考えています。

JDK 17

Beckwith 氏: Java は、JEP 403: Strongly Encapsulate JDK Internals (JDK 内部の強力なカプセル化) により OOP 原則をより積極的に実行するようになりました。Vector はプラットフォームに依存しない Vector API による計算。レコードなどの言語への追加やプロジェクト Valhalla などの JVM の改善により、多くの冗長性が削除され、不変性の概念がさらに取り入れられました。そのため、パフォーマンスを最適化する機会が提供されています。

Mihalceanu 氏: 今年は、LTS と非 LTS 両方の Java リリースで Java 開発者を驚かせました。Java 17 のリリースは、これらのプレビュー機能の多くが現在一般的で長期的に利用可能であることを確認しています。また、今でも Java 8 で実行されている一部のプロジェクトに、新バージョンに移行することへの切迫感も加わりました。Java 17 は、役に立つ NullPointerExceptions を持つという長年の夢を実現した LTS です。

Rahman 氏: いつものように、Java エコシステムのすべての部分で活気に満ちています。これは、Java の基本的な強みを物語っています。Java SE 17 は、特にレコードのような機能で特に好評だと思います。WildFly、Payara、OpenLiberty などのランタイムが Java SE 17 を採用しようとしています。一部の開発者は Java SE 11 を採用しましたが、残りの Java SE 8 は非常に粘着性があります。Java SE 17 がそれを最終的に変化させるかもしれません。

Ritter 氏: JDK 17 のリリースは重要です。これは、開発者がすべての OpenJDK ディストリビューションで新しい長期サポート (LTS) リリースが入手できることを意味します。安定性とセキュアを可能な限り維持して、6か月ごとに Java バージョンをアップグレードしたくない場合には、これは重要なリリースです。

プラットフォームに追加された小さな言語機能がこれまでにないほど速く目にすることを気に入っています。また、これは6か月のリリースリズムのおかげで、インキュベーターモジュールとプレビュー機能の両方を実用的にします。

チェックポイントでの協調復元 (CRaC) と呼ばれる OpenJDK の新しいプロジェクトなど、JVM をクラウド環境で機能するようにする方法のような興味深い開発がいくつかあります。レコードなどの機能は、新しいコードの開発に最適です。

Evans 氏: Java 17 LTS のリリースには、レコードとシールドタイプを活用するコードのデプロイを最終的に始められるようにする、JVM のグループを監視する JFR Streaming もあります。可観測性の分野、特に OpenTelemetry の標準化への道や、Java が静的にデプロイされる (「静的 Java」) ことの意味に関するコンセンサスの初期の兆候、また、Panama は人々が予想するよりも大きな影響があると思います。

OpenJDK のダウンストリームディストリビューション

Costlow 氏: 現在、差別化されていない JDK ディストリビューションが多すぎます。Microsoft に1つ、Eclipse は Temurin の Adoptium があり、Oracle には同社のと OpenJDK ビルド、Azul、AWS Corretto、Red Hat、Liberica、SAP Machine などがあります。Snyk の調査では、使用法に関して私が見たものと比較的一致しているように見えました。それらにはすべて互換性がありますが、新しい若い Java 開発者の決定を削除するために、市場で無作為抽出をする「Just get me OpenJDK (単に OpenJDK を私にください)」を見てみたいと思います。
特に Eclipse のブランド化は混乱を招きます。Adoptium は Eclipse 内のグループで、これもグループです。Temurin は皆さんが使うもので、OpenJDK です。あなた自身が Java を学び、次の文章を読んでいると想像してみてください。「Eclipse Temurin は OpenJDK ディストリビューションの名前であり、Adoptium からのものです」。ブランド名は少ないほど良いです。

Janssen 氏: Bellsoft の Liberica は、実際、他の JDK ベンダーと異なる非常に興味深い製品を提供しています。たとえば、今でも JavaFX を含んだ完全な JDK です。私は同様のビルドを提供しているのは ojdkbuild だけしか知りません。その次には、JDK と JRE のバリエーションがあります。

Azul は、非 LTS のバージョンを長期間のマイナーアップデートでサポートします。一部のベンダーは Docker イメージなどを提供しています。そのため、いくつかの違いがありますが、エンドユーザがそれらを比較して、どれを選択するとよいのかを決定することは困難です。

Java EE/Jakarta EE

Rahman 氏: Java EE から Jakarta EE への移行は、私たちの分野で最大で最も重要な技術移転の1つです。それはついに Jakarta EE 9.x で確固たる地位を築きます。Jakarta EE 10 が来年初めのリリースに向けてどのように進んでいるかを見ておくのは非常に良いことです。Jakarta EE アンバサダーの貢献ガイドの多くの項目が具体化して、長年のギャップを埋めているようです。これは、長期的な Java EE ユーザにとって大きな安心になると思います。

また、Jakarta EE 9.x が勢いを増しているのを見てとてもうれしく思います。Tomcat や Jetty などのほとんどのランタイムは、javax から jakarta へのネームスペースの移行を取り入れています。Spring Framework 6 は、Java SE 17 と Jakarta EE 9 両方の採用に取り組んでいます。同様に、MicroProfile 5 は Jakarta EE に移行しています。2021 Jakarta EE Developer Survey によると、かなりの数の開発者が jakarta ネームスペースに移行済みか、移行を計画しています。

Jakarta EE 10 Core Profile は Quarkus と Helidon の完全な互換性への道を開いており、MicroProfile Config API は新しい Jakarta Configuration 仕様に移行しており、MicroProfile Context Propagation でも同じことが起こっています。MicroProfile REST Client と JWT Propagation でも同じことが起こる可能性があります。

Redlich 氏: Jakarta EE 9 のリリースにより、ツールベンダーは新しい jakarta パッケージのネームスペースのサポートが可能になり、開発チームはアプリケーションを新しいネームスペースに移行してテストすることができ、ランタイムベンダーは移行と Jakarta EE 8 との下位互換性サポートのオプションと機能をテストして提供できます。

Jakarta EE 9 は、Jakarta EE 10 とその先の新機能を推進するイノベーションの基盤と見なすこともできます。

GraalVM/Spring Native

Mihalceanu 氏: ネイティブ実行ファイルの構築は「最も欲しい」とマークされることが多いもう1つのトピックです。より小さく、より高速なコンテナ化されたアプリケーションの競争が続く中。

Rahman 氏: Spring Native が進歩しているのを見ることもとても良いです。

Costlow 氏: ネイティブアプリの役割が具体化するのを見るのは好きですが、実際の仕様やワーキンググループがないことに失望しています。これは一種の「GraalVM が実行するものをすべて手に入れる」ようであり、標準の JDK の動作と異なる場合があります。類似していますが同じではありません。

Janssen 氏: Spring Native は、GraalVM と起動時間が速く、メモリ使用量が少ないその他のフレームワーク全てと競合します。

Silz 氏: Spring Boot が GraalVM によるネイティブコンパイルをサポートすると、高速で小さなネイティブ Java プログラムが主流になるでしょう。これにより、Java はサーバレスソリューションでより競争力を持ち、マイクロサービス分野で役立つ可能性があります。今日の時点では、JVM JIT は、GraalVM より長時間実行プロセスのスループット/パフォーマンスが優れていると考えているので「可能性がある」と言います。いずれにせよ、それは多くの Press を得て、Java を全体的に競争力のあるものにするでしょう。

ARM64/ARM の Windows

Beckwith 氏: ARM64 は汎用のハードウェアになりました。その結果、ARM64 のデプロイメントに最適化された Java 開発キットと Java ランタイム環境の存在が主流の人気を得ています。

Silz 氏: Java 16 は、ARM の Windows をサポートしています。しかし、macOS の ARM 対応の Java 17 だけがドアを大きく開くと思います。すべての Java 開発者の約4分の1が Mac を使用していると思います。そして2022年の終わりまでに、ARM を搭載した Mac しか購入できなくなります。これにより、ARM の Windows と Linux の両方がより良くなることも期待しています。

Jakarta EE と MicroProfile の調整 == Cloud Native for Java

Redlich 氏: Eclipse Foundation の後援による2つの補完的なイニシアチブである MicroProfile と Jakarta EE Working Groups が協力して、Cloud Native for Java (CN4J) を設立しました。これは、クラウドネイティブのブランディングと技術の両方で、Jakarta EE と MicroProfile の位置付けと調整を定義するためのアライアンスです。

Rahman 氏: Quarkus が Java EE と Spring 開発者の両方で十分な進歩を遂げているのを見るのは嬉しい驚きです。Jakarta EE と MicroProfile の調整が最終的に行われるのを見るのもとても良いことです。

JavaFX/Gluon

Costlow 氏: Gluon が単一の JavaFX コードベースをどこでも実行できるようにするために行っている作業に非常に感銘を受けました。Web はこれまで欠けていた部分であり、率直に言って、クライアント Java は今再びクールに見えます。

モジュールの採用

Silz 氏: JPMS は3つの問題を解決しようとしているように思います。アプリサーバのクラスロードの問題。JDK とすべての Java アプリケーションのより良い構造化。デプロイメント/ランタイムの JVM フットプリントの削減です。

しかし、少なくとも複数の遅延の後に JPMS がようやくリリースされた時には、これらの問題にはすでに十分な解決策がありました。クラスロードには OSGI。Java のプログラム構造にはドメイン駆動設計/クリーンアーキテクチャ/ Modulith/ArchUnit テスト。JVM のフットプリント削減のためには事前コンパイルのようにです。

信頼性の低いデータポイントはほとんどありません、それらはすべて、Java 8 以前の利用が Java 11 以降の利用よりも多いことを示しています。これは、Mark Reinhold 氏が認めているように、モジュールが原因で Java 9 以降に「Java 8 からのアップグレードが難しい」という評判を与えたことが一因だと思います。これは JPMS の意図しない結果です。そして、それはすべての Java 開発者の少なくとも半数を Java 8 に固執させ、過去7年間の Java の進歩を利用できないことを意味します。

おそらく7年以上モジュールに取り組む機会費用は、他の多くの Java の改善だったことを意味します。途中で挫折したか、Java 10 以降でしか表面化しなかったか。変数の var キーワード、新しいスイッチ構文、および Java レコードは、Java の悪名高い定型文の多くを削減します。もしそれらが Java モジュールではなく Java 9 にあったなら、開発者の生産性が向上して、Java は今より良い場所にあったと思います。

昨年から何が変わったのでしょうか?

Beckwith 氏: 多くのアーキテクトや開発者は、既存のコレクターの改善により、GC (ガベージコレクション) の停止時間を調整しました。他の多くは、ワークロードに合わせて低レイテンシのアダプティブ GC に移行して、テールレイテンシを抑えています。

Evans 氏: Java 11 は、市場シェアの点で Java 8 と本質的に同等になっています。コンテナは突破口を開き、現在、大部分の Java アプリのデプロイの方法になっています。Quarkus は成熟を続け、地盤と新しいファンを獲得しています。

Redlich 氏: いくつかの Eclipse Foundation Working Group が設立されました: MicroProfile、OSGi と Adoptium (以前は AdoptOpenJDK と呼ばれていました)。MicroProfile Working Group と Jakarta EE Working Group は、Cloud Native for Java (CN4J) アライアンスイニシアチブで協力しました。

Microsoft は、OpenJDK の独自のダウンストリームディストリビューションである Microsoft Build of OpenJDK を作成し、Java Community Process に参加することで、Java への取り組みを促進しています。

Java Community に言いたいことは何ですか?

Beckwith 氏: switch 文のパターンマッチング、ネイティブイメージ、クラウドネイティブ-JVM、それと アクセラレータの JVM、プロジェクト Loom と Graal。

Mihalceanu 氏: アップグレード。Java 言語の進化によって、フレームワークの機能も成長しました。私の経験では、クリーンでセキュアなコードを書くことは、チームが共有するプラクティスと即座に依存します。現在では、フレームワークに組み込まれた機能のおかげで、継続的テストと少数のローカル構成を使用して、コードの開発や修正にかかる時間を最小限に抑えることができます。

Rahman 氏: Java SE 17 と Quarkus が脚光を浴びています。Kubernetes は依然として非常に人気があります。Spring Native の周りには初期の活気があります。オープンスタンダードの Java コミュニティの人々は、Jakarta EE 10 と MicroProfile/Jakarta EE の連携を注意深く見守っています。エコシステムのすべての人にとって、かなり良いことが起こっています。

Ritter 氏: 少なくとも新しい開発に取り組む場合、ほとんどすべての開発者がフォーカスしているのは、特にマイクロサービスアーキテクチャを通じて、クラウドを最も効果的に使用する方法です。これらのタイプのアプリケーションを作成する場合、コンテナや Kubernetes、Spring Boot などの技術を活用すると非常に強力です。これらの使い方について多くの議論を聞いています。

Evans 氏: Java 17、Loom、Quarkus です。

私たちが予想していなかった、新しくてエキサイティングなことは何ですか?

Beckwith 氏: 私は、Java エコシステムの豊かさと、Java Dev Kits 製品のさまざまな JDK ベンダー別のフレーバーを予想していました。それでも、完全な参加と加速したリリースのリズムに向けた合意は、歓迎すべき驚きでした。

Mihalceanu 氏: 私が Java で気に入っているのは、リリースごとに言語と開発者のエクスペリエンスの両方が調整されることです。java.time.format.DateTimeFormatter クラスと DateTimeFormatterBuilder クラスで導入された期間の新しい日付フォーマッタ、スイッチのパターンマッチング、また java.util.stream.Stream インターフェイスのデフォルトメソッド toList() などの拡張は、開発者がよりクリーンで読みやすいコードを書くのに役立ちます。

Ritter 氏: Java プラットフォームを見ると、私たちが予測していなかったものは何もありませんでしたが、それは良いことです。新しい機能が JEP を使用して目的を定義するようになったので、数年先を見据えて Java に含まれるものの明確なロードマップができました。つまり、開発者は少なくともそれらを評価して議論するための十分な時間がなければ、下位互換性に影響を与える大きな変更がないことを安心できます。

Evans 氏: Azul や Red Hat など多くのプロバイダからのウォームスタート / サスペンドアンドレジューム / CRaC テクノロジーへの新たなフォーカス。

Redlich 氏: Java Persistence 企業である MicroStream の出現。彼らの歴史は2013年にさかのぼりますが、同社は2019年に正式に設立されました。それ以来、MicroStream 5.0 のリリースで今年初めに MicroStream をオープンソース化し、MicroStream が協力して Helidon と統合し、バージョン 6.0 をリリースしました。

Silz 氏: 何年にもわたる停滞の後、VS Code は Java IDE の分野で物事を揺るがしています。これは新しいことです。高速で、優れたプラグインを備え、ユーザに愛されているクロスプラットフォームのクロス言語のIDEです! それが「20年前のEclipse IDE」のように聞こえるなら、その通りです!

VS Code は最近、Java 機能を強化しました。私はそれが最高の無料の Java IDE になることを期待しています。Eclipse はその脅威を認識し、防御を調整するためにワーキンググループを設立したと思います。IntelliJ がどの程度影響を受けるかはわかりません。

Java 開発に VS Code を使用することのエキサイティングな副作用の1つは、JVM以外の言語で簡単に開発できることです。Eclipse でそれを行うことはまったくできないか、限られた方法でしかできないと思います。JetBrains の「All Products Pack」を使用して JVM 言語以外の開発ができますが、設定、プラグイン、またはキーボードショートカットが共通ではないさまざまな IDE を起動しなければなりません。

Java Community

Mihalceanu 氏: 私は大学在学中に Java の旅を始め、Java がデザインパターンとコーディングのベストプラクティスでオブジェクト指向プログラミングをサポートしていることを学びました。専門家として、私はこの言語が他のパラダイムも採用していることを嬉しく思います。したがって、関数型、リアクティブは、読みやすさを失うことなく、より多くの実装オプションを提供します。モデルを選択する方法は? ときにはアプリケーションのプロファイルを作成し、ボトルネックを見つけて、実装ロジックを改善します。

しかし、人がいなければ進歩はあり得ません。Java Community は大きく、活気があり、歓迎的であり、知識を共有し、自分自身を向上させ、問題に向き合って成功するという1つの目的のために物理的および仮想的な両方のすべてを提供します。

私たちの貢献者の視点はストーリーの一部しか伝えていないことに注意してください。Java エコシステムとロケールのさまざまな部分で、さまざまなエクスペリエンスが起こるかもしれません。2021年の私たちのレポートは、決定的な声明ではなく、議論の出発点と見なされるべきであり、業界が向かう方向性についてのオープンな議論に招待するものです。

関連記事:

• デベロップメント
• 設計/アーキテクチャ
• DevOps
• Spring
• Spring Framework
• Open JDK
• Java EE
• Java
• Architecture
• InfoQ
• クラウドコンピューティング

あなたのメールアドレスはこちら

国を選んでください。 選択してください InfoQ.com がプライバシーポリシーに従って私の個人情報を扱うことに同意します。

We protect your privacy.