Spring One 2021 で、VMware は、2022年10月のリリースを予定している Spring 6 が、さらに10年間のフレームワークの準備をどのようにするかについて明らかにした。Java 17 と Jakarta EE 9 が必要であり、Java モジュールとネイティブコンパイルのファーストクラスのサポートを提供し、Spring の可観測性を固め、そして時代遅れの機能とサードパーティの統合を削除する。Spring Boot 3 は Spring 6 を使用するが、リリース日は未定だ。
このオーバーホールの規模が明確になり、Spring Framework は2010年以来初めて今年の新しいメジャーリリースがない。ただし、Java 17 サポートの次のマイナーリリース、2021年11月と2022年5月のメジャーリリースである Spring Boot 2.x.y リリーストレインは引き続き提供される。
最近の開発者調査では、Quarkus や Micronaut などの新しいクラウドネイティブ Java フレームワークのアーリーアダプションが示された。これらのフレームワークでは、メモリ使用量が少なく、起動時間が短いネイティブアプリケーションを生成する。Spring 6 は、これらの競合するフレームワークに対する VMware の対応と見なされるかもしれない。
Spring 6 には、通常のオーバーラップしたメンテナンスリリースブランチがある。ただし「Spring Framework 6 のユーザは、機能リリースのストリームに参加することを強く奨励する。6.0.x を長期間使用することを期待するよりも、6.1、6.2 などのアップグレードを通常の使用モデルの一部にする。」
Spring Boot がすでに行っているように、リリースのリズムも年ごとから半年ごとに変わる可能性もある。
Java 17 を必要とすることについては、今日それほど積極的ではない。Spring 6 が出荷されるまでに、Java 19 がリリースされる予定だ。ベースラインとしての Jakarta EE 9 は、新しい jakarta パッケージ名前空間で下位互換性が壊れるが、Spring は維持できる: 一部の Spring 依存関係はすでに (Tomcat 10 や Jetty 11 など) Jakarta EE 9 をサポートしているが、(Hibernate ORM 6 のような) 他の依存関係は来年までサポートしない。
Spring 6 は Java Platform Module System (JPMS) を使用することと、開発者が JPMS を使用して Spring アプリケーションを作成できるようにすることが期待されている。
Spring Native は、今日 GraalVM による Spring アプリケーションのネイティブコンパイルを提供している。2021年11月19日に予定されている GraalVM 21.3 と Spring Boot 2.6 に依存するバージョン 0.11 のリリースでさらに改善される。ただし、Spring Boot 3 では、ネイティブコンパイルがスタータ構成およびビルドパックにシームレスに統合され、Spring 6 の Spring Native に置き換わる。
Spring Boot 3 が、すべての Spring Initializr ライブラリのネイティブコンパイルをすぐに提供することはなさそうだ。また、他のフレームワークの場合と同様、現在特定のJava ライブラリがネイティブモードで機能するかどうかを簡単に知る方法はない。
Spring Observability は Spring 6 の新しいプロジェクトであり、Spring Cloud Sleuth から学んだ教訓に基づいている。Micrometerを使用してメトリクスを記録し、OpenZipkin や OpenTelemetry などのプロバイダを介したトレースを提供する。エージェントベースの可観測性とは異なり、Spring Observability は、ネイティブにコンパイルされた Spring アプリケーションで機能する。またコアの Spring Framework の一部として、より効果的な優れた情報を提供する。
VMware は、削除予定の古い機能の例をいくつか提供した。つまり、名前/型によるオートワイヤーの setter、いくつかの FactoryBean の配置、および「特定の Web 関連オプション」だ。EJB と JAX-WS はサードパーティ統合であり、Spring 6 から削除されるかもしれない。
最初の Spring 6 マイルストーンは2021年後半に計画されており、候補のリリースは2022年7月に予定されている。VMware は、Spring および Spring Boot の計画に関するコミュニティフィードバックを募集している。
InfoQ は、VMware のシニアコミュニケーションマネージャの Kristen Strem 氏と最新情報について話をした。彼は、Spring Framework 6 と Spring Boot 3 についての質問で Spring チームとの連絡係を務めた。
バージョン 6 は、Spring Framework をさらなる10年のために準備します。なぜ必要だったのでしょうか、そしてなぜ今なのでしょうか?
業界が、JDK 8 をレガシーシステムのレガシーステータスとなり、最終的に次世代の Java を採用することで Java エコシステムに大きな転換点が見られます。JDK 17 はこのシフトに重要な役割を果たし、Java 言語、API、VM の拡張機能が蓄積された魅力的な新しい長期サポート世代が提供されることを期待しています。これは、サポートポリシー上の理由からほとんどがプレーンな JDK 8 の代替として採用されたばかりの JDK 11 LTS よりも優れています。さらに、新しい LTS 世代としての JDK 17 というだけでなく、JDK 17 のベースラインを維持しながらオプションでサポートする (Project Loom など) 予定されている今後の JDK 機能リリースで、さらに重要なメリットも期待されます。最終的には、6.x ラインで JDK 29 LTS までの JDK リリースを引き続きサポートします。
あなたは、Spring Framework 6.x の機能リリースと OpenJDK リリースモデルを比較しました。これは、新しいリリース 6.x が出た場合、以前のリリースブランチのリリースの作成を停止することを意味するのでしょうか?
オープンソースのメンテナンスリリースに関しては、通常どおりメンテナンスブランチをオーバーラップさせて、近年と同じモデルを維持します。OpenJDK リリースモデルは、Project Loom のサポートなど主要な機能を、新しい主要な世代のフレームワークとしてよりも、6.x の機能リリースに組み込む方法にインスピレーションを与えます。また、コアフレームワークレベルでより頻繁な 6.x 機能リリースを提供し、OpenJDK だけでなく、Spring Boot にも参加して年に2回反復して機能をリリースする可能性があります。大事なことを言い忘れましたが、Spring Framework 6 のユーザは、機能リリースのストリームに参加することを強くお勧めします。6.0.x に長く留まることを期待せず、6.1、6.2 などのアップグレードを通常の使用モデルの一部にします。
Spring 6 開発者が Kubernetes で実行中のアプリケーションをすばやくリロードしてデバッグする方法を示しました。これには Tanzu Application Platform が必要でしょうか? もしそうなら、これをすべての Kubernetes インストールで利用できるようにする予定でしょうか?
Kubernetes でアプリケーションのリロードとデバッグサポートのために、Tanzu 固有テクノロジーは必要ありません。Spring Boot には、v1.3 以来 Kubernetes で非常にうまく機能する devtools モジュールが付属しています。多くの場合、使用するツールとその構成方法について、いくつかの決定を行う必要があります。今年の Spring One で Dave Syer 氏が発表した「Inner Loop Development with Spring Boot on Kubernetes (Kubernetes での Spring Boot を使用した内部ループ開発)」の講演では、この概要が記載されています。
もちろん、Tanzu Application Platform の価値の一部は、Spring でうまく機能することがわかっているツールとの賢明な統合を提供できることと、開発者が心配する必要がないように多くのことを自動化できることです。これは多くの顧客が望んでいることであり、今年の Spring One 基調講演で自動化が機能していることがわかります。
Spring を含む多くのフレームワークは、ネイティブコンパイルに GraalVM を使用します。Java コミュニティ全体のネイティブコンパイルを改善するために Spring とこれらのフレームワークと協力することをどう思われますか? たとえば、Java ライブラリの GraalVM 互換のリポジトリと Spring One での GraalVM チームによるベンチマークについて言及しました。
Spring チームの焦点は、初日から、GraalVM チームとの緊密なコラボレーションを通じてネイティブ Java エコシステムの成熟を支援することにありました。Gradle および Maven プラグインを介してネイティブ実行可能ファイルをビルドおよびテストできるネイティブビルドツールは、その優れた成果物です。これは Spring チームと GraalVM チームによって開始され、JUnit プロジェクトにいくらか貢献しました。最近、Micronaut チームが力を合わせた同様のコラボレーションは Java エコシステムにとって非常に価値があります。
ネイティブ Java エコシステムをより持続可能で保守可能にする方法について Spring と GraalVM チームの間でビジョンを共有することで、ネイティブ構成プロジェクトでの深いコラボレーションも可能になります。これにより、さまざまなフレームワーク間でネイティブ構成を共有するためのガイドラインとツールが提供されます。この種の取り組みは、GraalVM ネイティブサポートの最近の改善 (ネイティブテスト、ネイティブ構成の改善、ビルド時のインライン化など) を活用することで可能になっていることに注意してください。
つまり、それは完全に問題のない、各フレームワークが独自の「秘密のソース」を提供することが期待されています。しかし、ネイティブ Java エコシステムは、Java ツールとライブラリでの共有サポートがなければ持続可能ではありません。Spring Boot 3.x ファーストクラスネイティブサポートの作業の一環として、より広いエコシステムとこの種のコラボレーションに引き続き多大な努力を払います。
4月に Spring Framework 6 で「コードベース全体にモジュール情報定義の導入」を検討していると Juergen Hoeller 氏は書いています。これは Spring Framework 6 が Javaプラットフォームモジュールシステムで Java アプリケーションを作成するためにすぐに使えるサポートをもたらすことを意味しますか?
Spring Framework 6 は、コア Java モジュールへの依存を最小限に抑えながら、すべてのコアフレームワークモジュールに module-info 記述子を導入することが実際に期待されており、JDK の
jlinkツールが Spring セットアップ用のカスタムランタイムイメージを構築できるようにします。オプションのサードパーティライブラリと特定の構成戦略には制約がある可能性があるため、そのような明示的なモジュールの使用が Spring ユーザの間でどれほど人気になるかはまだ不明です。最近の Java バージョンに多くの一般的な関心があるにもかかわらず、これまで、私たちはそれに対する多くの要求を受け取っていません。
関連する Spring One セッションのビデオとスライドが利用可能だ: Spring 6、Spring Native、および Spring Observability。