TypesafeのPlayチームはJavaとScala向けウェブフレームワークであるPlay 2.3を リリースした。 開発者が何より最初に気づくのはplayコマンドがTypesafe Activatorに切り替わっていることだろう。まだ元のPlayコマンドは全ての機能が使えるが、プロジェクトテンプレートとブラウザ基盤UIがPlayシェルの代わりに新しく登場し た。
Play 2.3は又sbt-webを 用いた良い資材管理ツールも持っている。Sbt-webはsbt プラグインの為の汎用フレームワークで、sbt-coffeescript, sbt-lessなどのクライアント側の資材制御の為に使われる。また、Sbt-webのお陰でPlayでWebJarsを使えるようにする。例えば、以下のようにたった一行の設定を追加することで、Bootstrapライブラリが追加される。
libraryDependencies += "org.webjars" % "bootstrap" % "3.0.0"Playのテンプレートライブラリは他のテンプレートエンジンも使えやすく、名前をTwirlに 変えて独自プロジェクトになった。又、WebサービスクライアントもPlayフレームワークから抽出され独立ライブラリとなった。
フレームワークの機能変更以外にも、Play 2.3には最近リリースされたScala 2.11(Scala 2.10も含む)のサポートとJava8を用いたより快適な開発のためのAPI改善が含まれたいる。（2.3ではJava7と8両方のサ ンプルを提供している。）
PlayのシンプルデータベースアクセスレイヤであるAnormは書き入れによるクエリ発行をサポートするように進化し た。
SQL"SELECT * FROM table WHERE id = $id"もしあなたがTypesafesのSlickを使っているのであれば、プラグインで登場したplay-slick integrationを使える。
websocketを用いた作業は前からPlayのIterateesのお陰で便利でした。2.3では、socketへ受信されたメッセージがactorへ転送又返信(サンプルコードはこ の文書を参照すること）はもちろんwebsocketをactorシステムと直接結び付くことが可能です。
InfoQはPlayの開発リーダであるJames Roper氏と話をする機会を得 て、最新リリースの新しい機能と彼らがフレームワークに対して彼らが持っている計画について話を聞いた。
InfoQ:一部のPlayユーザは今回、Play shellがActivatorに変わったことで驚いたと思います。これについてはどのように受け取ればよいでしょうか？
まず最初に、私はactivatorが単にUIからの起動とプロジェクト生成のようないくつかの新しい機能とsbt shellをUIでラッピングしたものに過ぎないことを指摘したいです。元々Play shell自体もsbt shellをラッピングし、新規プロジェクト生成などいくつかの機能を追加したものです。activator shellコマンドはplay shellコマンド代替しているため、あなたはactivatorでも完全に同じことができるので特に変化を意識する必要はありません。最初マイルストンでPlay 2.3を公開した時、我々は人達がこの点について気づかないことを目つけました。そしてそれはあなたが指摘したとおり多少の混乱と心配を招きましたが、今 は新しく公開したドキュメントとRC1のリリースノートを通じてこの点がスッキリされることを望んでいます。
Activatorが人々に愛される理由は生産性の高い開発環境を拡張し、進化した技術で作成されているからです。Typesafeで我々はこの開発環境を選択したのは、他のTypesafeと非Typesafeプロジェクトから異いとこを取り、Playを超 えてそれを拡張したいと思ったからです。我々はまたコミュニティーから寄付されるチュートリアルやPlay向け新しい開発ツールの基盤を新しい機能として提供したかったです。そしてその努力はPlay shellの配布が止まっている間、Activator shellによって振替えられ、ついに実を結ぶことができました。これらの機能がついにPlay 2.3で実現されたからです。
InfoQ: Playの基本データアクセスコンポネントはTypesafeのSlickではなく、 あいかわらずAnormです。今後、play-slickを積極的にPlayへ取込む計画は持っていませんか？又は今後もこのままサードパーティプラグイ ンとして残すつもりでしょうか？
それこそplay-slickをPlayのコアプロジェクトへ持ってきた意図で、既にそ れを望む声は ありました。でも、実際に取込む作業を行った際に、我々はある問題に直面しました。Play上でSlickが使われる一般的なパターンは依存性注入でし た。今まで我々はPlayが依存関係注入へ完全に従属されないように努力してきました。コンパイル時又は実行時のいずれに依存関係注入する仕組みが強制さ れますと、利用はもちろん文書化も依存関係注入から中立の立場にはならないです。 つまり、これは依存関係注入なしではPlay上のSlick利用に関してうまく文書化できないことを意味します。
我々は今回がそれを変えるチャンスだと思いました。でも、そこにはそのような主張を支える例題と文書化が必要でしたが、Play 2.3に載せるには遅すぎました。なので、我々はplay-slickをPlayに取込むことを2.4までに遅らせました。play-slickを正式にPlayフレームワークへ取込むためには、まず私達がユーザから信頼を得る必要があります。それに はこれからplay-slickをサポートし続けることとTypesafeもplay-slickの商用サポートを承認する必要があります。
InfoQ: Play2.3ではフレームワークのモジュール化関連の変更が多いようです。あなたは次のリリースまでこのことを続くつもりでしょうか？
そうです。私はこのようなことはどのフレームワークでも熟成による自然な流れだと思います。フレームワークの初期段階では、API変更による摩擦少なくし、フレームワークの進化を促進したり、ム新しい機能を早くリリースするため に、全ての機能を取込むことがより自然なことです。APIが安定化されることにより、モジュール化の良さがだんだん出てきます。それは個別のモジュールに自分のリリースサイクルを持たせて、そのモジュールのバグをより早く直して配布できることを意味します。も し、モジュール化がなかったら我らの厳しい互換性テストを満たせながらポイントリリースを行うのは不可能です。Play 2.4で我々は個別データベースライブラリのモジュール化を目指しています。
InfoQ: 次のリリースに対してのお話ですが、Play 2.4（さらに3.0も？)の計画について教えて頂けましょうか？
我々は既にアッ プデートロードマップを公開しました。ただ、そのロードマップは約束ではないのでご注意お願いします！でも、Play 2.4に向けての大きいタスクは依存性注入の戦略と、（実験レベルの）リアクティブストリームとakka-httpのサポートの導入、そして配布仕組みの 改善（Typesafeプラットフォームを通じた統合）です。
Play 3.0ではPlayが持っているグロバール状態を根絶したいです。そしてリアクティブストリームをPlayのベースレベルIOとして明確に導入したいで す。これは我々がいくつかのの特定のユースケースについての制限的なAPIを持っていることとは対照的に、Java上でユーザ定義ボディパー サーを作成する機能で、JavaユーザにとってPlayの全ての機能で非同期IOを実現可能にする道を開くことになるでしょう。
InfoQ:インタビュー、どうもありがとうございました！
新 しいPlay2.3をダウンロードした後には、現行アプリケーションへの適用を行うため、マ イグレーションガイドを読むことを忘れては行けない。