原文(投稿日：http://www.infoq.com/news/2011/12/spring31)へのリンク
SpringSourceはSpring 3.1の一般提供を開始した。InfoQは以前の記事で、Java 7のサポートや環境抽象化、キャッシュ抽象化というSpring 3.1の主要な特徴を紹介した。
InfoQはSpring frameworkの中心的なコミッタであるChris Beams氏に今回のリリースについて、また、Spring 3.2の計画について詳しい話を聞いた。
InfoQ: Spring 3.1は当初、6月末の一般提供を目指していました。なぜ遅れたのですか。
当初の計画ではSpringコンテナ用の完全にJavaベースの構成を提供するつもりでした。何度も実験を行い、マイルストンをひとつ達成するまで進みましたが、考え直しました。目的にしていた設計と適合しなかったからです。考えを変えました。全体の設計が終わった後、現在の@Enable*アノテーションのアプローチに落ち着きました。
また、Servlet 3.0は初期からサポートしていたので、Servlet 3.0の実装上の問題に直面しました。この実装がおかしくないことを確かめるためにいくつかのイテレーションを費やさなければなりませんでした。
しかし、遅れてしまった最大の理由は、Spring 3.2ではなく3.1でJava 7をサポートしようと意図的に開発スコープを広げたからです。fork/joinとJDBC 4.1のサポートまで手を広げました。また、可能な限り早くHibernate 4をサポートしようと決めました。Hibernate 4の最終的なリリースの前でもサポートしてしまおうとしたのです。現在、Hibernate 4のリリース候補版バージョン7をサポートしています。なので、Hibernate 4.0が正式にリリースされたらすぐにSpring 3.1.1にアップグレードする予定です。
また、スケジュールをきっちりを守って進捗するよりは、なるべく完璧なものをリリースすることを目指しました。凝集性と完全性を完璧にしようとしました。ユーザに意義があるフレームワークを確実に提供しようとしたのです。
InfoQ: Java 7のサポートを前倒したことで、Java 5や6よりも素早くJava 7が普及するでしょうか。
可能性はあると思います。Open JDKとIBMの両方から既にJDK 7をリリースしています。これは良い兆候です。私たちはOpenJDK 7上にTomcat 7が自然にフィットするように手伝ってきましたし、必ず上手くいくと思います。
Java 7が早く普及するのを願っていますし、普及と推進をある程度支援をするつもりです。開発者に門戸を開いたSpringのバージョンがあれば、普及は進みやすいと思います。
InfoQ: Spring 3.1が利用しているJava 7の機能には他にどんなものがありますか。try-with-resourcesやProject Coinの機能などはどうですか。
Java 7の機能については忘れていません(Java 8についても同様です)が、Spring 3.1が利用しているのはそれほど多くはありません。multi-catchやtry-with-resources、switch文での文字列による分岐のような新しい機能のほとんどはAPIに対して使うものです。APIの提供側に直接影響を与えるジェネリックのような言語の特徴とは違います。Spring 3.2はJMS 2を利用します。また、try-with-resourcesも上手く使うつもりです。
InfoQ: 環境抽象化の概念を導入しましたが、どのように使えばいいのか教えてください。
この環境抽象化はふたつのサブカテゴリに分類できます。ひとつはプロパティソースの抽象化、もうひとつはBean定義プロファイルです。
Javaで開発をする場合、システムの環境変数、JVM変数、実際に使うマップオブジェクトやプロパティオブジェクトなどを保存する場所は、データベースやキーバリューストアなど様々な場所があります。しかし意味的には、これらのプロパティは共通点があります。基本的にはこれらは環境毎に違う構成プロパティであるということです。プロパティソースの抽象化とはキーバリューペアの保存場所にアクセスできる単純なSPI[Service Provider Interface]を使ってアプリケーションを構成するということです。Springの環境ではこの方法を適用するために、これらのプロパティソースの階層構造を維持してユーザがプロパティを扱いやすくしてます。例えば、SpringのStandardEnvironmentはスタンドアロンのアプリケーションで利用しやすく、環境変数やJVMの変数をそのまま扱えます。また、ウェブアプリケーションの場合、StandardWebEnvironmentはServletのinit-paramsやcontext-paramsやJNDIプロパティを追加してくれます。抽象化された環境はコンテナやSpringのプロパティプレースフォルダを通じてとしっかりと統合されています。この仕組みは一環した抽象化を提供するのが目的です。つまり、"Spring、このプロパティの値を教えてちょうだい"と言えば済み、アプリケーションコードはその値がどこから来たのかを気にする必要はない。こうすることが目的です。
2つ目のBean定義プロファイルですが、これは条件によってBean定義の登録を制御できます。条件は普通、アプリケーションの配置環境(開発、テスト、運用、または、クラウドか従来の環境か)です。例えば、開発環境と運用環境を比べた場合、SpringのJDBC名前空間と組み込みデータベースビルダを使って組み込みのデータベースを使っていて、運用環境ではJNDIからデータソースを取得するという場合です。
これには以前から多くの要望をいただいてきましたが、今までのところBean定義プロファイルは好意的に受け止められているようです。開発者の皆さんがこれを様々な方法で活用してくれるのを楽しみにしています。
InfoQ: 今回のリリースのもうひとつの目玉はSpring Cacheです。Spring CacheとSpring Dataプロジェクトとの関係はどうですか。
Spring 3.1のキャッシュ抽象化は主にCacheとCacheManagerインターフェイスで構成されるSPIで、バックエンドのキャッシュプロバイダにアクセスします。また、@Cacheable、@CachePut、@CacheEvictのようなアノテーションが宣言的なプログラミングモデルを提供します。
Spring Dataは包括的なプロジェクトで、テンプレートクラスなどのSpringの仕組みを使って各データストアへのアクセスを実現するための設計を行うプロジェクトの集合です。これらのデータストアの多くは自然にキャッシュに適合できますし、統合作業を既に行っていたため、例えばGemFireやRedisをキャッシュサーバとしてそのまま使えます。GemFireとRedisはCacheとCacheManagerのSPIのすぐに使える実装を持っているからです。バックエンドの実装に関わらず、開発者は@Cacheable、@CachePutのようなアノテーションについて考えればいいだけです。
InfoQ: Spring Cacheはどのような点でJCache(JSR 107)と重複しますか。
JCacheは補助的なものです。また、JSR 107で仕様が定義されているので、SpringのキャッシュマネージャAPIのJCacheベースの実装を使うこともできます。例えば、インターフェイスがCacheManagerなら、JCacheCacheManagerを使えます。Spring CoreにEhcacheマネージャを組み込んだのと同じことです。そして素晴らしいことに、私たち自身でこれをSPIとSpring Data向けに今すぐ実装することができます。JCacheはほとんどベンダが広く普及しているので、JCacheのSPIを実装してくれると思います。そうなればバックエンドのプロバイダが何であるかにかかわらず、インターフェイスを簡単に取り替えられるようになります。
プログラミングモデルについては、アノテーションで重複している部分がかなりありますが、ある程度は予測できていました。意味が重複している場合もありますし、名前がJCacheで使われているアノテーションもありました。なので、私たち独自のアノテーションとJCacheのアノテーションの両方をサポートすることになるでしょう。これはSpring 2.5で導入した@AutowiredアノテーションをJSR-330の@Injectアノテーションをサポートするために調整したのと似ています。@Injectはその後標準化されました。
InfoQ: JSR 347には関心を持っていますか。Spring Cacheに影響があると思いますか。
私はJSR 347の専門家ではありませんし、この領域についても詳しくありませんが、この仕様のメリットは確実に意義があると思います。たくさんのデータグリッドや分散キャッシュプロバイダがありますが、どれも同じようなことを異なる実装で実現しています。JSR 347は遅れていた仕様を現実化し関係者が合意するようなある種の統合をもたらすことができる有力な候補だと思います。
JCacheのJSRがまだ完成していないことと、JSR-347がJCacheのJSRの上に構築されることを考えると、これ以上考えるのはまだ早いです。Springから見た場合、提供しなければならない機能が多くなりすぎるということはありません。基本的にはSpringは一貫したプログラミングモデルとバックストア向けの単純なSPIを提供します。JCacheから見れば、バックストアは単なるデータストアです。バックストアが分散化されている場合はまた別の問題です。これを調整するのはSpringのトランザクション管理のサポートと同じような方法でしょう。アノテーションンを使った方法やSPIを使う方法、また他にも様々な実装方法があると思います。例えば、JTAです。しかし、この実現方法はSpringのユーザから見ればどうでもいいことです。確かに問題かもしれませんが、プログラミングモデルの観点からは問題ではありません。
InfoQ: JMS 2.0とJCacheなどSpring 3.2について少し伺いましたが、他にもSpring 3.2で計画していることを教えてください。
仕様の点で言えば、JPA 2.1とBean Validation 1.1を検討している。また、SpringとJSF 2.2の相性が良いことを確かめています。さらに、完全に把握できていない領域についても様々な調査を行っていますが、例えば、並列プログラミングについては深く研究しています。Spring 3.1で既にしかし、fork/joinプールの基本的なサポートを導入しましたが、これによってアプリケーション開発モデルはどのように変わるのでしょうか。これは答えがはっきりしない問いです。私はSpringだけでなくコミュニティ全体のことを考えています。最終的にはこの答えをはっきりさせるだけでなく、ある程度のガイダンスとサンプルのアプリケーションを提示したいです。
非同期プログラムモデルについても同様です。Java開発者は今やServlet 3.0の非同期プログラミングの機能を利用できます。これは上手く動作します。しかし、この機能がSpringなどフレームワークにどのように組み込むのがいいのかは分かりません。例えば、サーブレッドで非同期機能を有効にした場合、リクエストパイプラインの他の部品は非同期の処理であることを意識しなければなりません。すべてリファクタリングしなければならないのでしょうか。その場合、フレームワークを使う開発者にはどのような影響があるでしょうか。フレームワーク自体にはどのような影響があるでしょう。
また、クラウドによってどのようにアプリケーション開発が変わるのかについても目を光らせています。今はPaaSが現存のJavaベースのアプリケーションをプラットフォームに乗せられるようにするために正しいことをしているかどうかを確認してます。WARベースの配置モデルやサーブレットベースのアプリケーションなどがそのまま動作するかどうかを確かめています。"クラウドの特性の中ではその方法が一番優れたやり方なのか"を問うのは本当に価値があることです。
ChrisはSpringのエラーレポーティングを再考していると言う。スタックトレースに対する依存を少なくし、javacの出力結果のようにして、CGLIBのプロキシ出力をより現代的な方式に置き換えるという。またSpring3.2の開発時にはバージョンコントロールをSubversionからGit(Hub)へ移行し、ビルドシステムをAnt/IvyからGradleにする予定だ。
Spring 3.2はかなり厳しいスケジュールで開発されている。リリースは2012の第4四半期の予定。