Oracleは本日この後のwebcastにおいて，Java EE 7を正式にローンチする。 リリースに先立ってInfoQでは，ソフトウェア開発担当副社長のAnil Gaur氏と対談し，今回のリリースと今後の計画について詳しく聞いた。
InfoQ Oracleが管理を引き継いで以来，今回が最初のJava EEバージョンアップになります。EE 6の時と比較して，何かプロセスに違いはありましたか？
私たちはJava EE 5の頃から，Project GlassFishの下で，オープンソースプロジェクトとしてJava EE のリファレンス実装を開発してきました。Oracleが管理するようになってからは，JCPのプロセスも以前に比べて明確なものになっています。OracleとJCPメンバはどちらも，プロセスのもっと早い時期からJava開発者コミュニティに幅広く関わっていきたい，と強く望んでいます。そのために，作成した仕様に対しては順次，レビューやフィードバックが可能なようにしています。JSRを透過的な方法で運用することの必要性を定義するため，私たちはJSR 348を起案しました。現在Oracleが主導するJSRは，すべてがこのプロセスに従っています。専門家グループには技術的な議論をするための電子メールのエイリアスが用意されていますし，暫定的なドラフト仕様をプロジェクトのページで見ることも可能です。
Java EEの仕様はすべて，このJSR 348の定義に従って作成されました。JCP専門家グループやJava EEベンダの他，これまでよりも広範なコミュニティが関与しています。このような開放的な方法が今回のリリースで良好に機能して，コミュニティからの参加者が大幅に増えたことは，大変喜ばしいことだと思っています。
InfoQ クラウドサポートが延期されましたが，Java EE 7全体としての重要なテーマはありますか？
Java EE 7を推進していく上で，実質的には３つのトップレレベルのテーマがあります。
1) ダイナミックスケーラブルなHTML5アプリケーションの配信
ブラウザ上でよりリッチなユーザエクスペリエンスを実現する手段として，HTML5の採用が急速に増えています。それに対して私たちは今回，WebSocketを導入しました。ユーザのプロトコルが動作するJava EEとブラウザの間に，低レイテンシの双方向通信チャネルを構築する手段となって，HTML5の採用を容易にします。一方では，HTTP上でRESTfulなサービスを実現するための非同期APIも導入しています。RESTfulなビジネスロジックを，スレッドを停止させることなくバックグラウンドで実行させることで，スケーラビリティを改善するためです。RESTfulなサービスでは，情報交換の手段としてJSONが頻繁に使用されます。そのためにJava EE 7では，JSON処理APIを導入しています。SAX的アプローチ，およびDOMオブジェクトモデル形式のアプローチを使って，JSONフォーマットされたデータを解析することができます。そして最後に，JSFフレンドリなマークアップがJSFに導入されました。これによりJSFページを直接，Webブラウザ内でレンダリングすることが可能になります。レンダリングされたページがどのように見えるかを確認するためだけに，JSFアプリケーションを実行する必要はありません。
2) 開発者の生産性向上
Java EE 7は開発者の生産性を大幅に改善します。一例として，ビジネスロジックのコアを完成するまでに必要な定型コードの量が削減されました。例えばJMS 2.0では，アノテーションや依存性注入，AutoCloseable，簡略化されたAPI，デフォルトリソース定義といったものを活用して開発量を減少しています。メッセージをキューに置くために必要なコードは，わずか数行にまで単純化されました。デフォルトリソース定義とは，JMSの接続ファクトリやデータソースなどにデフォルト定義を用意しておくものです。これによって，Java EEランタイムにアプリケーションをデプロイするのに必要なコンフィギュレーションが少なくなります。さらにもうひとつ，要求の多かった機能を追加しました。標準RESTfulクライアントAPIです。プロプライエタリなクライアントAPIを使うことなく，RESTfulコールを高い生産性で利用できるようになります。Java EE7をより統合されたプラットフォームにするために，JSRとの統合性改善にも多くの作業を行いました。例えば，メソッド定義内でのパラメータやリターン値の評価にBean Validationが使用できるようになりました。さらにコンテナ管理トランザクションがEJB以外でも利用可能になっています。トランザクションインターセプタと新しい@Transactionalアノテーションによって，任意のマネージドビーンのメソッドへのトランザクション適用が可能になりました。そして最後に，CDIがデフォルトで有効になりました。単にCDIビーンを使用するだけであれば，beans.xmlはもはや必要ありません。
3) 最も厳しい企業要件を満足すること
いくつかの非常に重要な企業要件に対処するために，新たに２つのJSRが提示されています。ひとつめはバッチAPIで，IBMが主導するものです。バッチAPIは非対話的，バルク指向，長時間動作の計算集中型タスクに最適です。企業ユーザの間で広く普及することになるでしょう。さらにはより多くのタスクを並列実行する手段として，並行処理ユーティリティ(Concurrency Utilities) APIを追加しています。Java EEはマネージドな環境のため，アプリケーションによるスレッド生成は許されていませんが，並行処理ユーティリティAPIによってスレッドプールを生成することで，タスクの並列実行が可能になります。
InfoQ: JCacheはEE 7の期限に間に合いませんでしたが，EE 8まで待たなければならないのでしょうか。あるいは実際には追加可能で，EE 7の標準サーバでも使用できるのでしょうか？
JCache APIについては，Java EE ８リリースまでの完成に向けて作業を進めています。プラットフォームの段階的なアップデートを通じて，Java EE 7上でも新しいAPIを利用可能にしていきたいと考えています。
InfoQ: Java EE 6のマネージドビーンと，バージョン5でプラットフォームに導入されたアノテーションベースのプログラムモデルとの組み合わせが，最終的にはEEコンテナの提供する任意のサービスを，任意のコンポーネント上で選択的に使用することを可能にしたように思われます。EE 7でもこの考え方が踏襲されているのでしょうか？
はい，その方向性は継続されています。最もよい例が，Java EEにおけるマネージドビーンの全体的なアライメントです。先に述べたトランザクションインターセプタがそのひとつで，トランザクションをこれまでよりはるかに柔軟な方法で適用できるようになっています。ビーンバリデーションの方がもっと一般的かも知れませんね - 必要ならば，ぜひ使用してみてください。同じようにJSF仕様では，JSF管理ビーンを使わずにCDIビーンを使用するように強く推奨されています。とは言ってもCDIビーンはデフォルトで有効になっていますので，単に必要な場合に使用すればよいだけの話です。
InfoQ: Java EE 6の重要機能にはもうひとつ， ポータブルエクステンションがあります。これはEE 7でも利用されているのでしょうか？
ポータブルエクステンションは，Java EE内部やユーザアプリケーションのいたる所で使用されています。Java EE 7内ではJMSやビーンバリデーション，JTAなどがすべてポータブルエクステンションを持っています。ポータブルエクステンションのみを目標とした，DeltaSpike というApacheプロジェクトもあるほどです。HK2 (GlassFish内) ではサービスを注入するために，クライアントコードからCDIの使用を可能にするポータブルエクステンションが使用されています。
Java EE 7に関連しては，必然的にいくつかの論争があった。JCacheとクラウド機能が乗り遅れたことに加えて，London Java Communityは，Message Service 2仕様が意欲的でなかった点について，その 最終リリース投票時に批判している。
LJCは，今回のJSRのコンテキストで実施された技術的作業を支持します。しかし，JMS 1.1のリリースを契機としてメッセージングの世界に起きたイノベーションについて考えるならば，今回のJSRはもっと意欲的，かつ広範囲を対象としたものであるべきだったと考えます。LJCはメッセージングに関して，さらなる標準化が可能であり，そうするべきものであると捉えています。関係JCPメンバに対しては，この方面での可能性を追求するように求めたいと思います。
InfoQではBenEvans氏とMartjin Verburg氏に連絡を取り，より詳細な話を聞くことにした。 Evans氏の弁:
私が期待していたのは，次のようなことです。
- ピア・ツー・ピアのメッセージングトポロジ
- ワイヤコンパチブルなメッセージフォーマット
- AMQP
- 超低レイテンシ・メッセージングの進歩
さらに私は，API更新へのアプローチに対して，EGが過度に臆病だと思いました。総称の欠如などはその例です。
加えてVerburg氏は：
今日の産業界において特に強調されているのは，特定の言語やプラットフォームに拘束されない通信プロトコル，という発想です。プログラム界のエコシステムがますます断片化されている現在，これは極めて重要なことです。キューあるいはメッセージバスは，アーキテクチャ的な関連を分離できるように設計されているのが通常です。それをJava特有のアプローチに限定してしまうことは，そのテクノロジの採用を回避するに充分な技術的理由を，人々に与えているのに他なりません。
ですからAMQP相互運用などの項目は，明らかに改善の必要な側面のひとつなのです。
同じようにJVM空間においては，もっと軽量なメッセージングを実現するために，他にもさまざまなアーキテクチャがあります。すべての付属物を取り払った，JMSのトリムダウン版を検討してみるのもよいでしょう。
そうは言っても，JMS 2.0には生産性を大幅に向上するものがありますから，JMS開発者に対しては，可能な限り早い移行を推奨したいと思っています。
我々はこれを，インタビュー相手のGaur氏に提示してみた。
JMS 2.0は，Java EE 7において大きく改修されました。ただし改良の余地は常にあります。私たちは今後も，JMS仕様の発展のために作業を続けるつもりです。リリースが持ち越された問題については，次期リリースの専門家グループでの評価が予定されています。さらに，Java EE 8のロードマップがもう少し確定したならば，コミュニティのメンバを招いて，彼ら自身の提案を次期バージョンのJMSに反映したいと思っています。London Java Communityが早い段階で，これに参加できることを望んでいます。
最後に我々はGaur氏に対して，我々がJava EE 8で目にするものが何であるのか，特にアイデアとしてのNoSQLや，アクション指向のWebフレームワークを中心に尋ねてみた。
クラウド機能については，大部分が以降のリリースへと延期されましたが，提供されている機能も一部あります。例えば，アプリケーションに必要なセキュリティ権限をpermission.xmlファイルに定義することが可能になりました。このファイルはアプリケーションにバンドルされます。Java EEランタイムがこれらの権限を確認できない場合，デプロイメントが失敗します。単純に実行時にエラーになるよりは，ずっとよい方法ですよね！先に述べたデフォルトリソース定義も，クラウド環境では便利なものです。デプロイされるアプリケーションは，PaaSプロバイダの用意しているデータベースなどのリソースへのマッピングとして，プロバイダの定義したデフォルトリソースに単純に依存すればよくなります。JPA 2.1ではスキーマ生成がサポートされました。未設定のクラウド環境へのアプリケーションのデプロイでも，データベーススキーマの生成と，データベースの事前導入が可能です。クラウド環境のJava EEにデプロイされるアプリケーションを，より可搬性のあるものにするにはどうすればよいか，私たちはJava EE 8以降を目指して検討を続けています。
NoSQLについては，未だイノベーションと変革が進行中の領域での時期尚早な標準化を避ける意図から，TBD (To Be Defined, 未定) としています。JCacheやState Management，JSON Bindingといった，すでに進行中のJSRについては，今後も取り組みを継続します。また，現在Java EEが提供しているDevOpsエクスペリエンスを向上するための構成サービス (Configuration Service) についても検討中です。上位レベルで見るとこれは，コンフィギュレーションの生成物と開発成果の分離に関するものです。例えば開発成果に影響を与えることなく，開発とテスト，運用環境にそれぞれ異なるコンフィギュレーションを適用するようなことが可能になります。データセンタではすでにWrite Once Run Anywhereが実現されています。これをクラウド上でも等しく実現するために，クラウドは必ず対応しなければならない部分です。その他の調査領域としては，あなたも言うように，Web開発者のエクスペリエンスを向上するものを検討しています。Java EE 7は大きな進歩を遂げましたが，Java EEで開発されたサービスを活用するエンド・ツー・エンドのモバイル／デスクトップアプリケーションに対する，開発エクスペリエンスの改善にはそれ以上のものがあると思っています。
Java EEに関する詳細は，今日この後の webcast で紹介される予定だ。