Java EE 8 の新機能概要のご紹介


この記事は、「Java EE Advent Calendar 2014」の19日目の記事となります。
昨日は、@nagaseyasuhitoさんの「JPAでマスター/スレーブ構成のMySQLを使うぞ」でした。明日は、@kokuzawa さんのご担当となります。

本エントリでは、今年の JavaOne で発表された、Java EE 8 (JSR-366) の今後の動向についてまとめたいと思います。

本エントリの内容は、JJUG CCC 2014 Fall で発表した内容に追加情報を加えた内容になっています。SlideShare で資料をご覧頂きたい方、もしくは PDF ファイルを入手されたい方は上記スライドをご参照ください。

本エントリの記載内容は、2014年12月時点での内容ですので、下記に記載する内容は今後大幅に変更する可能性もあることをどうぞご理解の上でご覧下さい。

まず、Java EE 8 のリリースに伴い、Java EE のスペックリードは本当に必要とされる技術が何なのかを改めて考えてみました。その際、業界のトレンドを観察し必要な技術は何なのかを検討したり、また Java の技術者の皆様にアンケートをとり、実際に技術者の皆様から求められている機能はどのような内容なのかも確認しました。アンケートの結果、JSON Binding, Security, JCache, Action ベース MVC 等が上位に占められていました。

こうして検討を重ねた結果、次の Java EE 8 のテーマを決めました。Java EE 8 では3つのテーマを元に機能提供を検討しています。

● HTML5
 + JSON Binding : JSR-367
 + JSON-P : JSR-374
 + Server-Sent Events : JSR は未定(JAX-RS,Servlet, WebSocket の何れか)
 + Action Base MVC : JSR-371
 + HTTP/2 のサポート(Servlet 4.0) : JSR-369
 + WebSocket の改善

● かんたん開発
 + CDI の適用範囲の拡大 : JSR-365
 + セキュリティ・インターセプタ
 + 仕様の削減

● クラウド環境への対応
 + Java EE Management 2.0 : JSR-373
 + Java™ EE Security API 1.0 : JSR-375

最新の Web 系の技術トレンドに対応するために、HTTP/2 への対応を Servlet 4.0 内で行うほか、Server-Sent Events の標準化、新しい Action ベースの MVC 等の導入も検討しています。また Java EE 5 以降、6,7 と継続してかんたん開発のテーマに取り組んでいますが、これは Java EE 8 でも継続します。例えば CDI の適用範囲をひろげ Java SE 環境でも CDI を利用できるようにします。さらにクラウド対応という点では、今まで Java EE アプリケーションを監視する際に使用していた、管理・監視用の JMX を改め、JAX-RS による監視を可能にする他、今までアプリケーション・サーバ毎に個別設定していた認証・認可の設定・実装(レルム)を標準化し、より簡単にユーザ管理のアプリケーションを実装できるようにします。これらの各種技術概要を見るだけでも Java EE 8 が待ち遠しくなりますが、それぞれの検討内容を下記にまとめて紹介します。

HTML 5 への対応として、ここに列挙する内容が検討されています。これらを順に説明します。

JSON Binding : JSR-367
JSON Binding は JSON と Java オブジェクトをマッピングし相互変換を簡単に実現するための機能です。

今までも、XML を利用する場合には、JAX-B を利用したり、データベースのテーブルと Java オブジェクトをマッピングするために、JPA を利用してきましたが、JSON-B はこれらと類似の方法で JSON と Java オブジェクトをマッピングできるようになります。またこれを実装する事によって JPA の Entity を使用したデータベース・テーブルから JSONへの相互変換や、JAXB を使用した XML と JSON への相互変換も容易になります。
JSON-B は JSON の Java へのマッピングにおいてできるだけ実装コードを少なくするため、Configuration by Exception のルールに乗っ取り標準でデフォルトのマッピング・ルールが提供されます。またクラスの継承も可能です。このデフォルトのルールに従う場合は、Java を簡単に JSON に変換できます。そしてもちろん、デフォルトのルールをカスタマイズしたい場合には、専用のアノテーションを付加する事でデフォルト・ルールを上書きする事もできます。
また、Java EE 7 で導入された JSON-Processing との連携も容易にできます。

JSON-B の参照実装は、Eclipse link MOXy で開発が進められています。

それでは、実際に Java と JSON のバインディングについて見ていきましょう。ここでは、Employee というクラスに、インスタンス変数、id, firstName, lastName, email が定義されており、Employee クラスのインスタンス (e) を生成した後、それぞれに値を代入しています。この Java オブジェクトを JSON で扱う場合、デフォルトのルールに従うとインスタンス変数名が、JSON の KEY になり、変数に代入された値が JSON の value として代入されます。

また、JAX-B をご利用した事のある方であれば、用語の説明は不要かと想定しますが、Java から JSON への変換を Marshal (マーシャル) といい、逆に JSON から Java への復元の事を Unmarshal (アンマーシャル) といいます。

Marshal (JavaからJSONへの変換), Unmarshal (JSONからJavaへの変換) を行うために、まず JsonContext オブジェクトのインスタンスを生成します。JsonContext のインスタンスを生成するためには、デフォルトで用意されているファクトリ・メソッド JsonContext#newInstance() を利用する事ができます。また下記のように JsonContextBuilder を通じてインスタンスを生成する事もできます。

JsonContext context = new JsonContextBuilder()
                  .setScope (MyClass.class, ...)
                  .excludeField(“field”, MyClass.class)
                  .addFilter(myContextFilterImplementation)
                  .build();

生成した JsonContext のインスタンスから、それぞれ createMarshaller() で Marshaller オブジェクトを、createUnmarshaller() で Unmarshaller のオブジェクトを生成します。

一旦、Marshaller オブジェクトを生成すると、変換したいオブジェクトを marshall() メソッドの引数に渡す事で簡単に JSON を含む String オブジェクトを取得したり、Writer として取り出す事もできます。

同様に、unmarshaller() メソッドの引数に JSON を含む String 、もしくは Reader から Java オブジェクトを渡す事で簡単に Java オブジェクトに復元する事もできます。

今まで JsonContext から Marshaller や Unmarshaller を生成し各処理を行う方法を紹介しましたが、よりかんたんに直接相互変換を行うためのユーティリティ・クラス Jsonb の作成も検討中です。Jsonb のメソッドを利用すると直接、marshal, unmarshal を実行する事もできるようになります。

JSON-B ではプリミティブ型や、参照型に対するデフォルトのマッピングルールを提供します。しかし、デフォルトのルールに従わず独自にカスタマイズしたい場合には、下記のようなアノテーションを付加しカスタマイズする事もできます。

例えば、デフォルトのルールに従うと、Java クラス中のインスタンス変数名は、JSON のキーに同一の名でマッピングされます。しかし、Java クラス中のインスタンス変数名と、キー名を変更したい場合は、@JsonPropertyアノテーションを付加して変更する事ができます。

また、Java のクラス中に含まれる特定のインスタンス変数を JSON にマッピングさせたくない場合、@JsonTransient アノテーションを付加し無効化する事ができます。

さらに、JSON ドキュメント中のキーの記載順に意味があるような場合、デフォルトでは Java クラスのインスタンス変数の記載順にマッピングされますが、その順番を変更するために、@JsonPropertyOrder アノテーションを付加し引数内に順番を指定する事ができます。

JSON-B では継承やポリモーフィズムにも対応予定で、また Marshal の前後、もしくは Unmarshal の前後に処理をインターセプトして何らかの処理を付け加えて実行したい場合に、それらを実現するための API (JsonPre***, JsonPost***) も用意しています。

JSON-Processing は Java EE 7 に JSR-353 として導入されました。JSON-P は Stream を利用して JSON の解析、生成を行うための低レベル API を提供し、XML における StAX や DOM のような機能を提供しています。
Java EE 8 では Java EE 7 で提供されている機能に加え、JSON の標準仕様に準拠した最新機能 (JSON ポインタや JSON パッチ) にも対応します。

まず、JSON ポインタについてご紹介します。

JSON ポインタは IETF RFC 6901 : JavaScript Object Notation (JSON) Pointer で定義される仕様で、JSON ドキュメント内に存在する特定の値を参照するための構文です。

たとえば、この例をご覧ください。この例では JSON 配列の中に、2つの JSON オブジェクト(名前が Duke と Jane)があります。そして人に関する情報(名前、性別、電話番号)が JSON オブジェクトとして記載されています。それではこの中から携帯電話の電話番号 (650-234-5678) を取得するにはどうすればよいでしょうか。JSON ポインタを利用すると、”/何番目/phones/mobile” といった形式で一意に値を取得する事ができるようになります。例では “0/phones/mobile” と 0 番目を指定する事で値を取得しています。

それでは、Java で JSON ポインタを扱うためにはどのようにすれば宜しいでしょうか。まず、先ほどの JSON ドキュメント(名前が Duke と Jane)が JsonArray のインスタンス contacts として表されている事とします。 この時、Json クラスのクラスメソッド createPointer() の引数に、参照したい JSON 値への参照パス(“/0/phones/mobile”)を渡し、JsonPointer のインスタンスを生成します。ポインタの getValue() を実行する事で JsonValue を取得する事ができます。またポインタに対して、replace を実行する事で、指定した参照の値を変更した結果の JsonArray を取得する事ができます(※ オリジナルを直接書き換えるわけではない)。

JsonPointer クラスには、ここで示すように様々なメソッドが用意されています。しかし、ここで1点注意をしなければならない事があります、add, replace, remove 等のメソッドは直接オリジナルの JSON ドキュメントに対する変更を行うわけではないという点です。JsonObject や JsonArray はイミュータブル(不変)のデータなので、直接それを変更するわけではなく、変更した後に新しい JsonArray や JsonObject を生成するという点に気を付けてください。オリジナルの JSON ドキュメントを編集したい場合は、JsonPointer ではなく、次に紹介する JsonPatch を利用します。

続いて、JSON パッチについて紹介します。
JSON パッチは、IETF RFC 6902 : JavaScript Object Notation (JSON) Patchで定義される仕様で、特定の JSON ドキュメントに対して行う操作(追加、変更、削除等)内容が記載された JSON のドキュメントのフォーマットです。JSON パッチのドキュメントは、op (add,replace,remove 等) と path (JSON ポインタ)が必須で、それ以外は必要に応じて追加できます。また、MIME タイプ “appliaction/json-patch+json” を指定し、HTTP の PATCH メソッドを利用できます。

※ JsonArray や JsonOBject はイミュータブル(不変)なオブジェクトなので、直接変更を加える事ができません。そこでオリジナルの JSON ドキュメントに対して、変更(追加、変更、削除など)を加えたい場合、新たに処理内容を記載した JSON ドキュメントを作成し、指定したドキュメントに対して操作を行う事ができるようになります。

下記に HTTP の PATCH メソッドの利用例をご紹介します。


PATCH /my/data HTTP/1.1
Host: example.org
Content-Length: 326
Content-Type: application/json-patch+json
If-Match: “abc123″

[
    { “op”: “test”, “path”: “/a/b/c”, “value”: “foo” },
    { “op”: “remove”, “path”: “/a/b/c” },
    { “op”: “add”, “path”: “/a/b/c”, “value”: [ “foo”, “bar” ] },
    { “op”: “replace”, “path”: “/a/b/c”, “value”: 42 },
    { “op”: “move”, “from”: “/a/b/c”, “path”: “/a/b/d” },
    { “op”: “copy”, “from”: “/a/b/d”, “path”: “/a/b/e” }
]

それでは、実際に JSON パッチのドキュメント記載方法と利用方法について説明します。まず、左側に示す、”mobile”:”650-234-5678″ の電話番号を (“650-111-2222”) に変更する場合を考えてみましょう。変更するために処理内容を記載した、JSON パッチのドキュメントを生成しますが、先ほど説明したように、op と path は必須です。ここでは既存の値を変更したいので、op には “replace” を指定します。また変更対象の値は、JSON ポインタで “/0/phones/mobile” と表す事ができますので、path にこの値を記載します。最後に value に変更後の値を指定する事で、電話番号を変更するための JSON パッチのドキュメントができあがりました。

また次に既存の JSON ドキュメントから要素を削除する例を確認してみましょう。この例では、0 番目を全部削除する場合を考えます。削除するために、JSON パッチのドキュメントを生成しますが、先ほどと同様 op と path は必須で、それぞれ remove と JSON ポインタで対象を指定します。

さて、基本的な JSON パッチの概念が理解できましたので、Java でどのようにしてパッチを扱うかについてご紹介します。オリジナルの JSON のドキュメントが JsonArray の target に代入されている事とします。また JSON パッチの記載内容が JsonArray の patch に代入されている事とします。Json クラスのクラス・メソッド createPatch(patch) を実行し、JsonPatch のオブジェクトを取得します。そして JsonPatch の apply メソッドをターゲットに対して実行します。このようにとても簡単にパッチを適用できます。

最後に、JSON クエリに対する Lambda & Stream API の適用についてご紹介します。JSON-P で提供される API の javax.json.JsonObject, javax.json.JsonArray はそれぞれ、java.util.Map, java.util.List インタフェースを実装したクラスです。そして、Map や List は Java SE 8 で導入された Lambda 式や Stream API を利用してバルク(一括)操作を行う事ができるようになります。具体的には、JSON ドキュメント中のデータのフィルタリングや変更(マッピング)などのバルク(一括)処理ができるようになります。下記に Java SE 8 の Lambda 式や Stream API を使用して JSON データに含まれるデータの抽出を行う例を紹介します。

Stream を取得するために、JsonObject, JsonArray で getValuesAs(JsonObject.class).stream() を実行します。一旦 Stream のインスタンスを取得した後は、java.util.stream.Stream で提供される filter や map といった中間操作用のメソッド、collect といった終端操作用のメソッドを、通常の Stream API と同様実行する事ができます。この例では、filter メソッド内で、性別が女性の方をフィルタリングし、 JsonObject として抽出しています、次に map メソッドで、抽出した JsonObject 中から、女性の名前を getString(“name”) で取得し、結果として String のストリームを返しています。最後に collect メソッド内で、結果を List として返しています。つまり List<String> femaleNames には女性の名前の一覧が代入されてます。

Lambda 式と Stream API を利用して JSON ドキュメントのデータの抽出等がかんたんにできる事が分かりました。しかし、Stream API の終端操作 Collectors で標準に提供する機能では、配列やリストなどへの変換しかできません。Stream API を利用して任意の中間操作を行った後、最終的に終端操作で直接、JsonObject や JsonArray のオブジェクトを取得できるとさらに有用です。そこで、Java EE 8 では java.util.stream.Collectors クラスを拡張した JsonCollectors を新たに提供する予定です。JsonCollectors では最終的に JsonObject や JsonArray を取得するためのメソッドを追加したり、groupingBy メソッドで結果のグルーピングをおこなうためのメソッドも提供する予定です。

具体的に JsonCollectors の利用例を紹介します。先ほどの例では collect で List を返していましたが、その代わりに collect で JsonCorrectors.toJsonArray() を指定する事で、結果 JsonArray オブジェクトとして結果を取得する事ができます。

最後に、今までご紹介してきた、JSON ポインタ、JSON パッチ、Lambda 式 & Stream API を使用して、オリジナルの JSON ドキュメントに対して一気に変更を加える例を紹介します。ここでは、電話番号のエリアコード(地域識別番号)で 415 を含むデータのみを抽出し、そのエリアコードを 415 から 650 に一括変更するための処理を記載します。まず、Stream を取得した後、filter メソッドで電話番号のエリアコードが 415 を含む JSONObject の Stream を取得します。次に、map メソッドで エリアコードの部分を 415 から 650 に変換するための JSON パッチを動的に生成し、生成した JsonObject の Stream を返します。最後に collect メソッドで、条件に一致する全ての変更用のパッチを含む JsonArray を生成し返します。パッチ用の JSON ドキュメント生成後、オリジナルの JSON ドキュメント(contacts) に対して、Json.createPatch(patch).apply(contacts) でパッチを適用する事で結果を取得しています。
このように、Lambda 式 & Stream API を利用する事で、より簡単にパッチの適用ができるようになります。

JSON-B に関する詳細は下記 JavaOne の発表資料「Java API for JSON Binding
Introduction and update
」もご参照ください。

ここでご紹介した API に関して、ご意見、ご要望がある場合は、メーリングリスト、JIRA などでお問い合わせください。

https://java.net/projects/jsonb-spec/

https://java.net/jira/browse/JSONB_SPEC/

続いて、Server-Sent Events (以降 SSE) について説明します。

歴史を少し振り返ると、サーバ側で発生するイベントをリアルタイムに通知するための仕組みは、今まで Ajax を使った Polling, Comet(Long Polling,Streaming), WebSocket が利用できました。Polling や Comet は、パフォーマンスが非常に悪く、大量のリクエストを捌くサービスを提供する事が困難でした。WebSocket はハイ・スケーラブルで双方向通信を実現できますが、専用のプロトコルを利用するため、これをサポートするクライアント、サーバ、さらに HTTP プロキシ等が必要でした。一方で SSE は純粋な HTTP を使用し、サーバ側からクライアントに対する一方向へのメッセージ通知としては利用できます。双方向通信ではなく、サーバからの一方向通信でよい場合、SSE は有用です。

SSE は、現在 W3C で仕様がドラフトとしてまとめられています。

http://www.w3.org/TR/eventsource/

SSE は、クライアントからサーバに接続しコネクションが確立した後は、サーバからクライアントに対して一方向でデータを送信します。この際、サーバ側で発生するイベントに応じて、何度も同一コネクションを利用してデータ転送する事ができます。MIME タイプとして専用のメディア・タイプ “text/event-stream” を利用します。SSE はクライアントがサーバに対してサブスクライブ(購読)要求をだして、サーバがサブスクライブしているクライアントに対してパブリッシュ(配信)するという点で JMS のパブリッシュ・サブスクライブのモデルに似ています。

現在、Java EE 上で SSE の実装を検討中ですが、どのレイヤーで実装するかを今まさに議論中です。具体的には Servlet 上、WebSocket 上、JAX-RS 上、もしくは独自のコンテナ上で実装する案があがっており、これらを検討中です。

検討案の説明資料:

https://java.net/downloads/javaee-spec/SSE-in-EE8.pdf

上記をエキスパート・グループメンバーに問い合わせ中ですが、現在、スペックリードとしては JAX-RS が一番適切ではないかと考えています。なぜならば、JAX-RS で既に HTTP のリソースに対するストリーミングをサポートしており小さな変更ですむためです。

● 小さな変更で実現
  例えば、JAX-RS でサーバ、クライアントにそれぞれ下記の API を追加します
  サーバの API として : EventOutput に対し新しいメディアタイプを追加
  クライアントの API として:Server側のイベントに対する新しいハンドラを追加
● 他のHTTPの操作と組み合わせる際に便利:新しいメディアタイプ
● Jersey(JAX-RS RI)は既に SSE をサポート済み
Jersey を利用した実装例はコチラ

JavaOne で発表された、次の JAX-RS で組み込む機能紹介の概要は下記よりご参照ください。
Let’s Talk JAX-RS.next! JSR-370 – What to expect in JAX-RS in Java EE 8

また、JAX-RS の参照実装 Jersey で既に実現している SSE の実装方法については下記をご参照ください。
Chapter 14. Server-Sent Events (SSE) Support

オリジナルの資料では Java EE 7 から導入された Concurrency Utilities for EE を使って説明されていなかったため、Concurrency Utilities for EE を使って書き直したコードを下記に記載します。ここでは、ManagedExecutorService を @Resource アノテーションでインジェクトした後、別スレッドで SSE のイベント通知を行っています。別スレッドの処理内容の例は、StockThread に記載しています。実際に SSE でメッセージ通知は EventOutput#send()メソッドで行っています。

また、SSE ではクライアント用の API も用意しています。これにより、JavaFX 等のスタンドアローン・アプリケーションでも SSE クライアントを実装し、SSE のサーバ・サイドからの通知を受信して何らかの別処理を行う事ができます。

次に、Action ベースの新しい MVC フレームワークについて紹介します。
Java EE 7 まで Web アプリケーションの開発を行う際、JavaServer Faces(以降 JSF), もしくは JAX-RS を利用できました。この中で JSF はコンポーネント・ベースの MVC フレームワークとして Java EE 5 以降標準の Web 開発フレームワークとして導入されています。一方、アクション・ベースの MVC フレームワークも世の中には多く存在します。例えば Struts や SpringMVC 等がこれに当てはまります。

Java EE の開発者にアンケートを実施した所「アクション・ベースの MVC は改めて必要でしょうか?」という質問に対し、約 6 割の方々が ハイと答えました。またその際、アクション・ベースのMVC を実装するために、「参考にすべき技術(デファクト・スタンダードな技術)はありますか?」と質問した所、75% の開発者は分からない、もしくは存在しないと答えました。

当初、JAX-RS のエキスパート・グループ・メンバーを中心に新しいアクション・ベースの MVC について議論を行いましたが、様々な議論を行った結果、JAX-RS とは別途、検討・実装した方がよいという結論になり、グループを再編し、スタンドアローンのAPI として、新しく JSR 371: Model-View-Controller (MVC 1.0) Specification として仕様策定を進めています。

※ 現在まさに仕様を検討中ですので、下記に紹介する内容は今後大きく変更する可能性があります。その点をどうぞご注意ください。

まず、MVC の各構成にどのような技術を適用するかを紹介します。アンケートの結果、参考にすべきアクション・ベース MVC が無い、もしくは分からないというご意見が多数あったため、既存の資産を有効活用するため Java EE で現在提供されている機能を組み合わせて、それらをつなぎ合わせて実装できるような MVC フレームワークを検討中です。Movel には CDI, Bean Validation, JPA 等を View は Facelets, JSP, 任意のテンプレート・エンジン(プラグイン可能なテンプレートエンジンが入れられると望ましい)等が予定されています。

一方で、現時点でまだ Controller 部分の実装が決まっていません。スペックリードが現在(10/29 から)この新しい MVC フレームワークのコントローラ部分をどのような環境で提供すべきかアンケートも実施しています。

https://java.net/projects/mvc-spec/lists/users/archive/2014-10/message/68

(A) Layer MVC on top of the Servlet API: define new set of annotations, new URI mapping algorithm and new data binding layer for controllers. This option implies no MVC + REST controllers, at least not in a elegant manner (see example on e-mail thread).

(B) Layer MVC on top of the JAX-RS API: reuse existing set of JAX-RS annotations, URI mapping algorithm and data binding layer for controllers. This option implies that MVC + REST controllers will be possible, but also that our runtime will depend on the JAX-RS runtime.

メーリングリストでの回答の多くは、(A) の Servlet API 上に Controller 実装を希望している方が多く見られるようです。一方、Oracle (Santiago) としては (B) に投票予定のようです。

(3) Oracle’s Vote: We have been busy writing some prototypes and evaluating
MVC frameworks for the last few weeks. We are not taking this decision
lightly as it obviously has a great impact on future work. Our main concern
has always been familiarity of existing APIs and duplication of work,
especially around matching (routing) and binding. These are the list of
annotations that JAX-RS defines for this:

* Matching: ApplicationPath, Consumes, Produces, GET, PUT, POST, DELETE,
HEAD, OPTIONS, Path, HttpMethod

* Binding: BeanParam, CookieParam, DefaultValue, Encoded, FormParam,
HeaderParam, MatrixParam, PathParam, QueryParam, Cookie, Form

And this is just annotations, no matching and binding semantics, etc.
This fact, together with the existence of several MVC frameworks built on top
of JAX-RS, has led us to the conclusion that JAX-RS is right technology for
MVC to be layered on. Thus, Oracle votes for option (B).

下記に JavaOne 発表時のサンプル・コードを示しますが、上記の投票結果や今後の進捗によって今後大きく変更される可能性があります。

上記では、JSP や Facelets で <form action=”/rough-example/form1a.jsp”> を記載し、ページ内に EL 式を用いてデータ・バインディングができるようになっています。またサーバ側では、クライアントのリクエストに対応する処理を @Path を付加したメソッド内で記述し、メソッドの戻り値として画面遷移先を返しています。

Java EE におけるアクション・ベースの MVC フレームワークのプロジェクトはまだ始まったばかりです。ご興味のある方は是非、java.net に存在するプロジェクトやメーリング・リストにご参加ください。

JSR 371: Model-View-Controller (MVC 1.0) Specification
The MVC specification project : java.net

HTML 5 関連で最後に、HTTP/2 対応についてご紹介します。
HTTP/2 は Internet Engineering Task Force(IETF)の Hypertext Transfer Protocol Bis (HTTPbis)のワーキング・グループで標準化が進められている、次バージョンの HTTP プロトコルです(現在はまだドラフト)。HTTP/2 の特徴として下記のような物があげられます。

* レイテンシを軽減
* Head of Line Blocking 問題の対応
* 並列処理のサポート(複数コネクションは不要)
* HTTP 1.1 の意味は保持
* HTTP 1.x との連携を定義

Java EE で HTTP/2 に対応するために、JSR 369: Java™ Servlet 4.0 Specification で対応を行います。Servlet API は、HTTP/1.x に対応していたため、単一リクエストに対し単一レスポンスを返すアーキテクチャになってました。この問題点として、例えば、同一クライアントからサーバに対して大量の HTTP リクエストを行うような場合、特定のリクエストで処理時間を多く要した場合、後続の処理が待ち状態になり全体としてパフォーマンスが低下する場合がありました。しかし HTTP/2 ではよりデータ転送の効率化をはかるために、単一コネクションで、リクエストとレスポンスを多重化できるようになります。これにより、例え一つのリクエスト処理に時間を要しても後続の処理に影響が発生しにくくなるため、より効率的なデータ転送を行う事ができるようになります。

Servlet 4.0 における変更点の詳細は下記に記載していますので、下記をご覧ください。

また、JSF 2.3 における変更点は下記ごご覧ください。

続いて、「かんたん開発」の分野における Java EE 8 の拡張ポイントについて説明します。まず、CDI の適用範囲が大幅に広がります。

CDI は Java EE 6 で導入され、Java EE 7 まで、Java EE のコンテナ、つまりアプリケーション・サーバ上で利用されてきました。実際、CDI の仕様である JSR 299 は Contexts and Dependency Injection for the Java™ EE platform として記載されていました。しかし Java EE 8 からは、JSR 365 として Contexts and Dependency Injection for Java™ 2.0 に名前を変え、CDI の適用範囲を Java EE 外にもひろげ、Java SE 環境でも利用できるようにします。これにより、EJB の組み込み可能コンテナと同様に、JUnit のテストコード等でも CDI を利用できるようになります。

Java EE 8 に含まれる CDI 2.0 では、大きな機能拡張としてここにあげる3つの機能があります。

また、上記以外にも下記のような機能拡張も予定されています。

● イベント処理の拡張
● インターセプター・デコレータの仕様への対応
● SPI の拡張
● コンテキストの拡張
● Java 8 機能への対応(タイプ・アノテーション、アノテーションのくり返し、Lambda, Stream, デフォルト・メソッド、型推論)

詳しくはWorking method for CDI 2.0をご参照ください。

まず、Java SE 環境で利用可能にするために、CDI を Java SE 環境で起動するための Bootstrap 用 API が提供されます。

CDI 2.0 first Face to face meeting feedback によると、下記のようなクラスの提供を検討しているようです(まだ議論中との事)。上記会議での議論の内容は CDI 2.0 の新機能を理解する上で重要ですのでご興味のある方はどうぞご覧ください。

public class ContainerBoot {

    /**
     * Simple boot
     */
    static BeanManager initialize() {
      ...
    }

    /**
     * Boot with parameters
     */
    static BeanManager intialize(Map&lt;?,?&gt;) {
      ...
    }
    void shutdown() {}
}

つづいて、モジュール化について説明します。CDI は Java EE 6 における標準化以降、Java EE において非常に重要な機能になっています。そして、EJB 等で培ってきた経験を元に、EJB が持つ機能も多く CDI に取り込まれて利用できるようになってきており、この方向性は今後も引き続き継続されそうです。この中で CDI が機能を持てば持つ程、CDI 自身が大きく、重量になる事も懸念されてます。そこで、CDI 自身を引き続き継続して軽量に扱う事ができるように、CDI 自身のモジュール化を検討しています。

上記では①、②、③と示しましたが、実際にはより細かく検討されています。

A. 単純な DI の機能
B. Observer パターンを利用した CDI によるイベント管理機能
C. 対象型の発見方法の拡張
デプロイしたアプリケーションの起動時に型検査を行う
D. (A+B+C+AOP:インターセプタ、デコレータ)
E. D+コンテキスト管理

詳細は CDI 2.0 modularity proposal をご覧ください

また、EJB の MDB に変わり、CDI でも非同期メッセージを受信するための新しい API も検討中です。現在の MDB の実装は、たくさんの設定が必要で MessageListener を implements したクラスの実装も必要でした。
今回、JMS をさらに簡単に利用でき、任意の CDI に対して利用ができるようにします。また、MessageListener を implements したクラスの実装も不要で、直接メソッドに @JMSListener のアノテーションを付加し、監視する Queue を destinationLookup で指定し実装できるようになります。

また、Java EE 7 までの MDB と同等の振る舞いを実装するためには、該当の CDI に対して @Singleton アノテーションを付加する事で MDB と同等の振る舞いを実現できます、また @Transactional アノテーションを付加する事でコンテナ管理のトランザクションも正しく動作します。ここに記載したコード例のように既存の MDB の実装に比べより簡単に実装できるようになります。

Java EE 7 まで提供されてきた認可(Authorization)用のアノテーションとして、@RolesAllowed や @RunAs といったアノテーションが存在しました。これらのアノテーションは多くの利用場面に有用でした。しかしより複雑な認可処理が必要な場合、別途、認可用のプログラミングを実装するか、もしくは新しく CDI のインターセプタを実装する必要がありました。また認可用のアノテーションを実装する際に、EL 式が評価できるようになる事でより多くのユースケースにかんたんに対応できるようになります。

今回、ロールに基づく認可の他、Java EE のコンテキスト情報にもアクセスし、コンテキスト情報から認可情報(プリンシパル名、ロールチェック、認可チェック)を取得する事も可能な新しいアノテーションを、CDI のインターセプタとして実装する予定です。

詳細は、JIRA に登録されている JAVAEE_SPEC-29 : EL-Enabled Authorization Annotation をご覧ください。

また、上記以外にも、CDI との連携をより強化するために、様々な場所でクリーン・アップを行います。例えば、WebSocket の実装においても CDI のスコープを利用できるようにしていますが、このように CDI が他の仕様でも幅広く利用されている事がわかります。

WebSocket の拡張に関しては下記の Slide もご参照ください。

また、Java EE 8 では Pruning (剪定:仕様の削減) 候補として EJB 2.x のリモート、およびローカルのクライアント・ビュー(EJBObject, EJBLocalObject, EJBHome, EJBLocalHome インタフェース)があげられています。さらに CORBA : (Prune CORBA interoperability) もあげられています。理由として昨今 SOAP や REST で通信を行う事が多く CORBA の利用場面が大幅に減ってきているためです。現在これらを用いて実装している場合は、アップデートをご検討ください。

最後に、Java EE プラットフォームの近代化(クラウド環境への対応)を行うための機能を紹介します。

まず、Java EE Management & Deployment API について説明します。
JSR 77: J2EE™ Management という JSR において、Java EE のプラットフォームで提供される管理オブジェクトを定義していました。これらの管理オブジェクトの各インスタンスは、構造化された OBJECT_ID で識別され、管理オブジェクトは追加機能を提供するために、コンテナ側で下記インタフェースを実装する事もできました。そして、これらの管理オブジェクトは、JConsole 等のツールを利用して管理、監視を行ったり、独自に管理・監視機能実装してアプリケーション全体の運用管理を行う事ができました。

EventProvider : 設定イベントの通知 : GlassFish 実装
StatisticsProvider:統計情報採取 : GlassFish 実装
StateManageable:状態管理(基本的なライフサイクル) : GlassFish 実装

今回提案する仕様では、現在の実装方法に代わり、REST インタフェースで管理可能な、管理オブジェクトを定義する事を目的としています。これにより、既存の HTTP のツールやライブラリを用いてかんたんに Java EE アプリケーションの管理ができるようになります。またこれにあわせ、エキスパート・グループ・メンバーは、既存の Management EJB の API や JMX API をオプションにするべきかどうかも検討中です。これは仕様をかんたんにするためという理由だけではなく、今回提案する REST インタフェースをより積極的に採用していただくためです。

新しい REST インタフェースは、既存で提供している OBJECT_NAME を URL に変換し、また個々の管理オブジェクトに対する CRUD 操作も可能です。EventProvider のイベント通知に Server-Sent Events もサポートする予定で(WebSocket も検討中だが、対応ツール(HTTPのアップグレードは不要)リアルタイムで監視する事ができるようになります。

また、JSR 88: Java™ EE Application Deployment という JSR において、デプロイ・ツール用のインタフェースが定義されていました。そしてこれに準拠したデプロイ・ツールから、個々のアプリケーション・サーバに対して直接アプリケーションをインストールする事ができました。JSR 88 のサポートは Java EE 7 からオプション化されています。

デプロイ用の API も上記、REST インタフェース内に取り込む予定です。このインタフェースを利用する事で、アプリケーション・サーバのインスタンスに対して、REST インタフェースを通じて直接アプリケーションをインストールする事ができるようになります。その際、依存するリソース定義や管理も REST インタフェースを通じてできるようになります。

次にセキュリティについて説明します。現在、セキュリティの設定・実装に関する多くがアプリケーション・サーバ固有設定になっており、これにより移植性が大きく損なわれていました。今回、これらサーバ独自の設定を排除し標準化する事で、クラウド環境でより柔軟に移植性の高いアプリケーションの構築が可能になります。
これらは、JSR 375: Java™ EE Security API で検討中です。

まず、パスワード・エイリアスを導入します。これまで、アプリケーション・サーバからデータベースや、LDAP 等の外部リソースへの接続するためには、サーバ側の設定でユーザ名、パスワードを設定していました。所がこのユーザ名、パスワード管理はアプリケーション・サーバ固有で、一部のアプリケーション・サーバでは生のパスワードを記載しなければならない場合もありました。データベースや LDAP への接続用のユーザ名やパスワードを生の形で見えるようにしておくのは非常に危険です。そこで、生パスワードを記入しなくてもよい標準の方法を提供します。

@DataSourceDefinition{
  name=“java:app/MyDataSource”,
  className=“com.example.MyDataSource”,
  …
  user=“duke”,
  password=“${ALIAS=dukePassword}”)

上記の構文は、現在 Java EE の参照実装 GlassFish で採用されているパスワード・エイリアスの指定方法で、標準化にあたりこれをベースにしていますが、パスワードの値には、実パスワードを参照するためのエイリアス(仮の名前)が設定されており、実行環境が必要に応じてエイリアスから元の実パスワードを参照するようになっています。

ご参照:Password Aliasing for EE 7

続いてユーザ管理について説明します。Java EE 7 までユーザ管理(認証・認可)を扱うアプリケーションの実装は、各アプリケーション・サーバ・ベンダーに依存していました。つまり統一的なユーザ管理用の API も用意されていなかったため、概念は共有できても実装コードは個別に行う必要がありました。以前、GlassFish v4 で始める Java EE JDBC レルム ハンズオン・ラボ として GlassFish 上で Java EE6/7 利用者向けのハンズオン・ラボを公開しましたが、ここで記載した内容は他のコンテナではそのままでは利用できません。そこで、このようなユーザ管理を行うアプリケーションを作成する際の、標準化を行い移植性の高いアプリケーションを構築するため、ユーザ管理機能の標準化が行われます。
この仕様もまた、JSR 375: Java™ EE Security API 内で行われています。また、JIRA に登録されている JAVAEE_SPEC-9 : Simplify and standardize authentication & role mapping もご参照ください。

ユーザ管理を行うために、3つのコア・クラスを提供します。これらを順に紹介します。

● UserSourceDefinition:データ・ソース(DB, LDAP, ファイルなど)を定義
● UserService:ユーザの管理(追加、変更、削除など)機能を定義
● UserInfo:ユーザ情報の定義(ユーザ名、パスワード、有効期限など)

UserSource(DB, LDAP, ファイル、その他)のリソース中に含まれるユーザ、グループを UserService で処理し、個々のユーザは UserInfo として管理され、ユーザ名、パスワードだけでなく、有効期限や、アカウントのロック状態なども管理ができるようになります。

具体的に、LDAP からユーザ、パスワードを参照するアプリケーションを作成する例をここで紹介します。@LdapUserSourceDefinition というアノテーションを付加し、ユーザ情報が含まれる LDAP ディレクトリをしていします。またこれを利用する為には、@Resource アノテーションを付加し UserService をインジェクトしています。UserService のインスタンスを取得した後は、下記に示すメソッド(現時点での仮案)を利用してユーザ管理、グループ管理を行う事ができるようになります。


+ UserInfo:loadUserByUsername(username)
+ changePassword
+ createUser
+ deleteUser
+ updateUser
+ userExists
+ createGroup
+ addUserToGroup
+ removeUserFromGroup
+ isUserInGroup

また、UserInfo のインスタンスは下記のフィールドを持ち、ユーザ自身の管理も標準で用意にできるようになります。

+ Username
+ Password
+ AccountExpired
+ AccountLocked
+ PasswordExpired
+ Enabled
+ Attributes

続いて、ロール・マッピングについて説明します。ロール・マッピングもユーザ管理同様、アプリケーション・サーバ固有に設定・実装が必要でした。ロールマッピングの実装もまた標準化を行います。

ロール管理を行うために、2つのコア・クラスを提供します。これらを順に紹介します。

● RoleMapper:ロール情報が保存されるデータ・ソース(DB, LDAP, ファイルなど)を定義
● RoleService:ロールの管理(権限の付加、排除、権限の有無チェックなど)機能を定義

RoleMapper(DB, LDAP, ファイル、その他)のリソース中に含まれるロール情報を RoleService で処理します。

ここでは、メモリに存在するロール情報を元に、ロール管理を行うアプリケーションを作成例を紹介します。ここでは、@MemoryRoleMapperDefinition アノテーションを付加し、その中でロール情報を定義しています。ここで定義されたロール情報を元に @Resource アノテーションで RoleService をインジェクトしインスタンスを生成しています。getRolesメソッドの引数で与えられたユーザが持つ全てのロール一覧を取得するために、getRolesForUser(username) を実行しています。RoleService が提供するメソッドの一覧(現時点での仮案)は下記の通りです。


+ grantRoleToUser(username, role)
+ revokeRoleFromUser(username, role)
+ hasRoleForUser(username, role, includeGroups)
+ getRolesForUser(username, includeGroups)
+ getUsersWithRole(role, includeGroups)
+ grantRoleToGroup(group, role)
+ revokeRoleFromGroup(group, role)
+ hasRoleForGroup(group, role)
+ getRolesForGroup(group)
+ getGroupsWithRole(role)

このように、ユーザ管理用の API やロール管理用の API が標準化される事で、よりかんたんにユーザ管理アプリケーションが実装できるようになるだけでなく、移植性の高い認証・認可のアプリケーションを構築できるようになります。

Java EE 8 は 2016 年の秋頃を目処に仕様を FIX し提供する予定です。

また、これに向け Java EE 8 は JSR 366 として登録され投票の結果、満場一致で承認されました。

詳細なロードマップは上記ですが、Java EE 8 の正式リリース時には、今までと同様 GlassFish が参照実装として提供される予定です。

現時点で登録済みの Java EE 8 関連の JSR 一覧を下記に示します。下記 JSR もどうぞご参照ください。

● JSR 366: Java Platform, Enterprise Edition 8 (Java EE 8) Specification
● JSR 107: JCACHE – Java Temporary Caching API
● JSR 365: Contexts and Dependency Injection for Java™ 2.0
● JSR 367: Java™ API for JSON Binding (JSON-B)
● JSR 368: Java™ Message Service 2.1
● JSR 369: Java™ Servlet 4.0 Specification
● JSR 370: Java™ API for RESTful Web Services (JAX-RS 2.1) Specification
● JSR 371: Model-View-Controller (MVC 1.0) Specification
● JSR 372: JavaServer Faces (JSF 2.3) Specification
● JSR 373: Java™ EE Management API 2.0
● JSR 374: Java™ API for JSON Processing 1.1
● JSR 375: Java™ EE Security API

その他、メンテナンス・リリースとしてここに示す各既存 API の改善も検討されています。

Java EE 8 の今後にご興味のある方は Java EE プロジェクトにご参加頂き、メーリング・リスト等でフィードバックをください。

Adopt-A JSR プロジェクトを通じて、日本 Java ユーザ・グループの一員としてフィードバック等をおこなってください。

最後に、Java EE 7 が日本で本格的に導入されるのは 2015 年からですが、Java EE 7 のプロジェクトを開始するにあたり、その先の Java EE 8 の変更点等を理解し意識した上でプロジェクトを進めていく事は、将来の移行、更新において非常に有用です。例えば、Pruning 予定の EJB 2.x の機能を使っているかた、Java で CORBA の利用をご検討中の方は時代の流れをいち早くつかみ、そうしたコードを排除する事がより安全に長く使っていただくための秘訣です。また認証・認可の実装コードも将来標準化される予定のクラスやメソッド・シグネチャを理解しておく事で、移行も用意になるかと想定します。Java EE 8 が市場で投入されるようになるのは、2017 年後半〜2018年辺りになる事が予想されるので随分先の内容ですが、将来の動向もみながらどうぞ今のプロジェクトをお勧めください。2016 年にリリース予定の Java EE 8 をどうぞ楽しみにしてください。

2014年12月19日 at 10:00 AM コメントをどうぞ

JavaOne 2014 現地レポート


月曜日から本格的に JavaOne のセッションが始まりました。JavaOne 参加者は約 500 程あるテクニカル・セッションから、事前に興味のあるセッションを選んで受講していくわけですが、全て受講すると 朝 8:30 〜夜 9:45 まで非常にハードなスケジュールになります。特に人気のあるセッションは、満員で入れなくなるセッションもあったりします。例えば Java EE のスペック・リードである Linda Demichel が Java EE 8 に含まれる予定のテクノロジーの概要を紹介したセッションは予想通りの満員セッションでした。

私は Java EE 関連のセッションを受講する事がおおく、基本的には Parc 55 にいるため、ヒルトンホテルで行われている Java SE, JavaFX, Java Embedded にご興味のある方々とは、なかなかお会いできません。

しかし、ヒルトン・ホテル側には、展示会場や、グッズ販売のお店、Duke’s Cafe 等があるので、時間の合間をみて訪れるようにしています。

グッズ・販売コーナでは、Duke 人形や Java ロゴの入った洋服、書籍販売等が行われています。

また、展示会場では実際のエンジニアに詳しく各製品技術に関して聞く事ができる場所なので、色々な製品を見たり、また説明員の方やエンジニアと交流を持って頂くのもよいかと思います。CloudBees のブースで Jenkins の作者で同社 CTO の川口耕介さんとお会いしたので久しぶりにご挨拶をしました。

今年は、日本から NTT さんが HeapStats という Java VM のトラブル解析ツールを展示会場で展示されていましたのでご挨拶もかねて伺いました。

また、JavaOne はセッション受講ももちろん重要ですが、Java のエンジニアやキーマンと直接交流を持ち親交を深める事もとても重要です。
今年、JCP が誕生して 15 周年の記念の年ですが、JavaOne 開催期間中に JCP 15 周年パーティが開催されていました。JavaOne 開催直前に JCP に正式参加された楽天の方と共に JCP パーティにも参加してきました。JCP の Party では最も優れた JSR や、最も優れたスペック・リード達が表彰されたり、Adopt a JSR の参加で素晴らしかった JUG 等も表彰されていました。

左側から一緒に参加した
Arshal Ameenさん(楽天)
Patrick Curranさん(JCP PMO の議長)
Donald Smithさん(Java SE Product Manager)
岩崎 浩文さん(楽天)

パーティだけではなくもちろん展示会場にもスペック・リードやエンジニア、キーマンは常にいますので、展示会場に足を運びそうした方々と直接話しをするのもとても楽しいと思います。こうした交流がまさに JavaOne の醍醐味です。参加者の皆様にはここでしかできない事を是非色々と体験して頂ければ幸いです。

今日は3日目です、夜には Oracle Appreciation Event が開催され、エアロスミスやその他複数のアーティストによるコンサートも行われます。今年も日本からの参加者の皆様とご一緒に参加する予定です。参加者サンフランシスコの夜はとても寒いのでコートを着てお越しください。

2014年10月2日 at 12:05 AM コメントをどうぞ

JavaOne 2014 基調講演レポート


Java の将来にとって Java コミュニティは重要
(※ 文言、内容等修正をする可能性があります。)

●「Java とコミュニティ」
2014 年 9 月 28 日、JavaOne San Francisco 2014 ストラテジー・キーノートを皮切りにはじまりました。

今年の JavaOne は昨年よりも来場者が増加し、モスコーンセンターに世界中から非常に多くの Java 開発者が集まりました。基調講演を取りまとめたのは昨年に引き続き Java Product Management Vice President の  Peter Utzschneider で今年の JavaOne のテーマ “CREATE THE FUTURE” (未来を創る) を発表しました。

Peter は冒頭で、JavaOne は開発者による開発者のためのイベントとして位置づけ、このイベントは、Java コミュニティからのフィードバックを受けて、昨年以上により良いイベントにするために様々な趣向を取り入れ実際に実現していると説明しました。

例えば、社外の方々も含むコンテンツ選定委員の絶え間ない努力のおかげで、500 以上のセッションを選定しラインナップしています。

また今や JavaOne には必要不可欠となった毎年恒例のイベントとなった Geek Bike Ride も JavaOne 開催に先駆け、土曜日に開催されました。この Geek Bike Ride は世界中の開発者とよりよい交流を持つ事ができる貴重なイベントですので、今年参加できなかった方も是非来年に参加してくださいと Peter 自らが話をしていました。また、展示会場においても様々なイベントやショーケース、参加型のイベントなども用意している事を紹介しました。


さらに、今年のテーマは“CREATE THE FUTURE” (未来を創る) ですが、まさに将来を担うのは子供であり、今の子供達が将来 Java の開発者になるため、子供達に対するプログラミング教育の重要性を説き、JavaOne に先駆け子供向けのイベントを開催しました。元々は Devoxx というヨーロッパに存在する Java コミュニティが立ち上げた自らの子供達に Java を教えるイベントでしたが、その取り組みが世界的に評価され今や世界各国で Devoxx4kids というイベントが開催されています。JavaOne 前日に開催された Devoxx4Kids に実際に参加された子供達が壇上に招かれ、実際にイベントで取り組んだ内容を紹介しました。


また、Peter は Java の将来を創っていく上で欠かせないのは Java コミュニティの力で、Java の開発者に Java のコミュニティに参加する事の重要性を紹介し、実際に行われてきたコミュニティの活発な活動例や創造性、情熱などを紹介しました。一つ目はドイツの例でドイツに存在する 22 の JUG が共同でイベントを開催し2日間のイベントを成功におさまた事や、ロンドンの Java コミュニティでは Java SE 8 のLambda 式を勉強するための新しいツールを作成中で、もうすぐリリースされる事を紹介した他、Java のユーザ・グループとしてはロンドン、ブラジルに続き3つめとなりますが、モロッコの Java コミュニティがJCP のメンバーに参加した事も発表しました。

また、JCP に関連した内容として JCP は今年で生誕 15 周年を迎える記念の年で、Java の継続的な成長と成功のために標準化が重要である事、そして継続して技術革新をおこなうために開発者自らが標準化に対する積極的の重要性を伝えました。JCP の生誕 15 周年を祝うイベントも JavaOne 期間中に開催することも述べました。

今、世界規模で驚くほど Java のコミュニティが新規に立ち上げられており、昨年の
JavaOne から1年間で 80 以上のコミュニティが作られていることを紹介しました。
Peter はオラクルにとって Java コミュニティはとても重要で、コミュニティに対する投資は継続し、開発者との交流を大切にし、コミュニティを通じて次の Java を作りたい、Java の開発者と新たな関係を構築したいと語りました。

●「Java SE の現状と今後」
Peter は引き続き Java SE を紹介するために、Java Platform Development の
Vice President である Georges Saab を壇上に招きました。

Java SE 8 は世界中のコミュニティから長い間期待されていた機能が含まれており、
正式リリース後、様々なメディアで取り上げられ、統合開発環境もいち早く
対応し素晴らしい反応を得ている事を紹介しました。また中でもリリース以降
すでに、8 カ国語で 80 以上の Java 8 に関連した書籍が出版されている事をあげ、
OpenJDK や JCP における透明性の開発の結果、いち早く情報が得られる事、
そしてコミュニティ・メンバーの多大なる努力のおかげと伝えました。

Java SE 8 は近代的なプログラミング手法(関数型プログラミングやコレクションに対する一括処理など)を取り入れ、それ以外にも JavaFX, JavaScript エンジン、サブセットを提供するプロファイル等も取り入れたため、かつてない程の Java に対する変更が加わっているものである事を紹介しました。

また、パフォーマンスに関しても様々な箇所で大幅に改善しているため、Java SE 7 に比べ 40 % のパフォーマンス改善が見込まれ、運用面においても大きな利点が得られる点を言及しました。さらに、Java にとってセキュリティは非常に需要であるため、継続的に四半期に一度セキュリティのアップデートを提供することを紹介した他、

また、エンタープライズ領域で Java を使用する場合に、 Mission Control,
Advanced Management Console といった機能、さらにはサポート契約に
ついても紹介しました。

最後に、今後のロードマップとして Java SE 8 のアップデート予定、さらには
次期 Java SE 9 のリリース計画についても紹介し、Java SE 8 の利用を
呼びかけ、Java SE 9 もアーリ・アクセス版を試してフィードバックを提供して
欲しいこと伝え壇上をさりました。

●「Java Embedded の適用領域の拡大」

Java Embedded 1年間の急速な普及

ー 1年間で 50万ダウンロード
ー 20 以上のデバイスへのポーティング
ー 業界全体でのコラボレーション
ー オンライン学習サイトへ 83カ国 2400 以上の登録

Peter は引き続き、Java Embedded 関連の紹介を始めました。Embedded の領域で Java ME の CDC は Java SE のコンパクト・プロファイルに置き換えられ、組み込みの分野においても標準の Java SE の API の殆どが共通的に使えるようになっておりツール等も共通で使える事を紹介しました。そして Java SE との差分はデバイスに対するアクセスのような限定的な物となっていることを紹介し、今では Java の開発者は、組み込みのデバイスからデスクトップ、さらにはサーバ・サイドのアプリケーション開発まで同じ文法で同じライブラリを使用することができるようになっており同じ Java のスキルで開発者の幅が広がっている点について紹介しました。
Java SE Embedded 8 では Compact Profile で Mission Control, Flight Recorder 等が利用できる点を紹介し 8 月にリリースした Java SE Embedded Update 6 ではパフォーマンス改善などもおこなっている点を紹介しました。

また、新しく Java Embedded に関する新しいプロダクトのリリースも発表しました。

Java ME Embedded 8.1 EA リリース
基調講演であらたに、Java ME Embedded 8.1 のアーリ・アクセスをリリースした事を発表しました。
Oracle Java ME Embedded 8.1 Early Access Downloads

これは、ARM Cortex M3/M4 マイクロコントローラや、mbed を含む Freescale FRDM k64 ボードのサポートなどが含まれます。

Java とモバイルに置けるイノベーション
ー Oracle Mobile Application Framework
ー Java Card
ー RoboVM
ー Java for Trusted Execution Environment

Java はモバイル分野でも大幅な進歩をしていますが、Oracle の Mobile Application Framework はクロス・プラットフォーム・アプリケーションの開発が可能になっています。

Peter は IoT Device のアーキテクトである Jasper Potts と Richard Bair を壇上に招き入れ、Java Embedded で作成した車の制御アプリケーションのデモを行いました。これは車を模したボードで、車のペダルを踏むと速度表示パネルに速度がリアルタイムで表示され、タッチデバイスに表示される地図に位置情報を示し、地図をタッチしてを操作したりできるようになっています。さらには温度の測定、光度の測定など、各種センサーからの情報をリアルタイムに取得し、それらの情報をもとに車を制御したり、クラウド上にデータを送信したりする事ができるようになっています。
サーバ・サイドは Java EE 7 のアプリケーション・サーバを使用し、車とサーバ間は WebSocket の通信を行っています。これら全てが Java で実装されており、次世代の車でできる一部を参加者はみることができました。


●「活気のある Java EE」

続いて、Peter は Cloud Application Foundation の Senior Vice President である
Cameron Purdy を会場に招き入れ、Java EE の説明を Cameron に譲りました。

Java EE 6 に準拠するアプリケーション・サーバは 20 超え、Java EE 7 準拠のサーバも各社が積極的に対応をすすめています。また、Java コミュニティからも Adopt-A-JSR プログラムを通じて将来の Java EE の為に、積極的な貢献を頂いています。さらに開発環境においても著名な統合開発環境におけるJava EE 7 のサポートを提供し開発生産性が大幅向上する他、高品質なアプリケーションを作成するために、Hudson, Maven, Arquillian 等を使用する事ができます。

また、GlassFish に関しても商用サポートの打ち切りは行いましたが、Java EE の参照実装の基礎として GlassFish に対しては継続して投資を行っています。

また、最近次のバージョンである Java EE 8 に関する JSR が JSR-366 として JCP に登録され、最初の投票が行われましたが、Java EE 8 に関する投票は満場一致で承認されました。
Java EE 8 に含まれる機能は、世界中の Java EE の開発にアンケートを実施し、必要とする機能に関してフィードバックを頂いた後に検討した結果を踏まえた内容となっています。

Java EE 8 に含まれる機能例
ー JSON Binding
ー Java Message Service 2.1
ー Servlet 4.0
ー Model View Controller
など

Java EE 8 の議論はまだ始まったばかりですが、Java EE 8 は 2016 年の秋リリースの予定で現在進行しています。
最後に Cameron は Java コミュニティの参加社に Adopt-A-JSR というJavaコミュニティが将来の Java を創るために貢献できるプロジェクトをご紹介し参加を呼びかけました。

●「Duke Choice Award & Java EE コミュニティ・パーティ」
基調講演と同日「Duke Choice Award」の授賞式や、Java EE コミュニティの
パーティ等がありました。Duke Choice Award は今年で 13 年目という事もあり
13組の受賞者が発表されています。また、授賞式の後は、世界中の Java EE のコミュニティメンバーがあつまるパーティもあり、多くの日本人が海外のエンジニア達と交流をもっていました。

[Duke Choice Award]





[Java EE Community Party]


●「まとめ」
今年の JavaOne 基調講演では、最新の Java 情報に精通する開発者にとっては既知の内容が多く含まれていましたが、それは JCP の改革によるものです。Java の開発は現在全てオープンな場でディスカッションが行われ、プロセスを進めています。その為事前に得られる情報が多くなっているのも事実です。
一方で、この Java の透明性によって、開発者はいち早く事前に情報を収集する事が可能なため、今のような製品がリリースされた直後から大量の書籍や情報を入手できるようになっています。
JavaOne には1週間で 500 以上のセッションが存在し、Java に関する様々な情報を入手できます。また、Java の仕様を決める方や世界のエキスパートと直接意見交換ができる貴重な場ですので、そういった国際交流を持つ事も JavaOne の一つの楽しみ方かと思います。

Let’s Enjoy JavaOne !!

PS.
最後に、Peter が話をしていましたが来年の JavaOne は Java 生誕 20 周年の記念の年となります。来年の JavaOne はさらに色々な趣向をこらした内容を用意する予定ですので、来年もぜひご参加ください!!と申しておりました。

2014年9月30日 at 8:01 PM コメントをどうぞ

javac コマンドの-source, -target オプションのルール変更について



Java SE 5 以前の Java のソース・コードを Java SE 7, Java SE 8 の環境でご利用頂いている皆様に、今後の JDK における仕様変更(予定)のご案内をさしあげます。

※ この情報は 2013 年 4 月 14 日に開発者 (Joseph D. Darcy) からアナウンスされた情報です(ご参照:Changing Sources and Moving Targets: Evolving the javac command line )。また、JEP(JDK Enhancement Proposal) 182 としてリストされている内容です。

今まで、javac のコンパイラ・オプションで “-source”, “-target” オプションを使用し、過去のバージョンで作成した Java のコードを現在の target で指定した Java の実行環境上で動作させる事ができました。

例えば、下記の簡単な AWT で実装したコードをご覧ください。ここでは、Frame の親クラスである Window クラスの Windows#show() メソッドが Java SE 5 で deprecated になっています。

import java.awt.Frame;

public class Test{
    public static void main(String argv[]){
        Frame frame = new Frame();
        frame.setSize(300 , 150);
        frame.show();
    }
}

上記のコードを、JDK 5 以降のバージョンでコンパイルすると下記のワーニングが出力されます。

ここでは、JDK 7 でコンパイルした例を示します。

> javac Test.java
注意:Test.javaは非推奨のAPIを使用またはオーバーライドしています。
注意:詳細は、-Xlint:deprecationオプションを指定して再コンパイルしてください

> javac -Xlint:deprecation Test.java
Test.java:8: 警告: [deprecation] Windowのshow()は非推奨になりました
frame.show();
^
警告1個

この J2SE 1.4 で実装されたコードを Java SE 7 の環境で動作させるためには、コンパイル・オプションに下記の “source”, “target” を指定する(bootclasspathは 1.4.2 の rt.jar を指定)事で Java SE 7 の環境で実行させる事ができました。

> javac -bootclasspath /tmp/rt.jar -source 1.4 -target 1.7 Test.java

今回、JEP 182 で提案された内容は、上記の ”source”, “target” で指定できるバージョンについてのルール変更です。

まず、Java SE 8 で Java SE 5 以前のバージョンが指定された場合に、「deprecated (非推奨) 」であるワーニングメッセージを出力するように変更されています。実際に、Java SE 8 の環境で ”source” に 1.4 を指定した場合の例を下記に示します。下記のように、Java SE 8 からワーニング・メッセージが出力されるようになっています。

> javac -bootclasspath /tmp/rt.jar -source 1.4 -target 1.8 Test.java
警告: [options] ソース値1.4は廃止されていて、今後のリリースで削除される予定です

警告: [options] 廃止されたオプションについての警告を表示しないようにするには、-Xlint:オプションを使用します。
警告2個

そして、Java SE 9 では Java SE 5 以降 以前のオプションを完全に削除するという内容になっております、もっと正確に申し上げるならば、今後の Java のリリースにおいて1プラス3バックのルールが採用されるようになります。

● Java SE 9 リリース時に指定可能な値: 9/1.9, 8/1.8, 7/1.7, 6/1.6
● Java SE 10 リリース時に指定可能な値: 10/1.10 9/1.9, 8/1.8, 7/1.7

この変更を行う理由ですが、Java の 1.0 のリリース以降、クラス・フォーマットは非常に多くのバージョン・アップを重ねており、Java コンパイラのメンテナンス・コストが非常に高まっています。このメンテナンス・コストを軽減するための措置として変更が考えられています。どうぞご理解の程宜しくお願いします。

日本においても、上記の仕様変更によって影響のある環境も少なからずあるかと想定します。現時点でも、Java SE 5 以前のコードを Java SE 8 以降の環境で動作させる事は非推奨となっております。また、Java SE 9 では上記を実現する事もできなくなります。仮に Java SE 5 以前のコードが存在する場合には、お早めに、deprecated なクラスやメソッドを取り除き、Java SE 7, 8 等の最新の環境で正常に動作するように移行をご検討いただければ誠に幸いです。

2014年7月2日 at 12:55 PM 1件のコメント

JavaOne 2014 San Francisco につきまして


JavaOne 2014 ディスカウント・コードのご案内


本日は、日本 Java ユーザ・グループ (JJUG) に所属する方々へ、JavaOne 2014 San Francisco のディスカウント・コードをお知らせいたします。今月 (6 月) 中に JavaOne 2014 San Francisco への参加チケットをご購入頂ける場合、JJUG 会員の皆様には現在の早期割引価格に加えて、さらに追加で $200 OFF でチケットをご購入頂く事が可能です。これは、当日のオンサイト価格に対して $600 OFF の割引になりますので、この機会にどうぞご登録ください。

ディスカウント・コードをご利用されたい場合は、登録時に下記をご入力ください。
※ ディスカウント・コード: DJU4

今年の JavaOne は継続して Java 開発者が必要とする情報をお届けするイベントで、9トラック 400 以上のセッションが用意されております。また、下記ブログでも情報共有されましたが、今年は次期Java EE 8 に関する情報も提供される事と想定しています。
Java EE 8 のプランニング

JavaOne には皆様が欲しい情報が必ずあると思います。是非、今年の JavaOne への参加をご検討ください。

また、これに併せて、JavaOne 2014 San Francisco のオフィシャルツアーにつきましてご案内を差し上げます。

JavaOne 2014 オフィシャルツアーのご案内



【JavaOne 2014 San Francisco オフィシャルツアーお申し込みページ】

 
★ お申込締切:2014年 7月 31日(木) 17時 ★

ご旅行代金:198,000 円(2名様1室利用時*1の1名様あたり料金)
※ 1室1名様ご利用も可能です
(追加ご旅行代金 上記および135,000円、合計 333,000円)
上記旅行代金には日本から米国までの航空運賃は含まれておりません。
詳細は上記サイトをご覧ください。

本ツアーは、ホテル代金、空港送迎、JTB 特設デスク(日本人)ご利用等をご利用頂く事ができ、2名1室でもご利用頂ける、JavaOne 参加者向け特別パッケージでございます。宿泊先の The Westing St. Francis はJavaOne 会場である、ヒルトン・ホテル、ホテル・ニッコー等から目と鼻の先にある、安全で好立地な場所に存在します。

Expedia によると
本日時点で、JavaOne 開催期間中のユニオンスクエア周辺の9/27-10/3までのホテル代金の平均は1泊 ¥45,940 でございました。
3つ星ホテル:¥51,968
4つ星ホテル:¥67,360
5つ星ホテル:¥75,237

一方で、本パッケージをご利用頂いた場合2名1室の場合、¥39,600 一人の場合、¥66,600となります。(The Westing St. Francis:4つ星ホテル)

JavaOne の会場からとても近く好立地で、安全な場所に宿泊されたい場合、是非、本パッケージのご利用をご検討頂ければ幸いです。(空港送迎の他、現地で日本人によるサポートもございます。)本パッケージは会社の同僚、もしくは Java のコミュニティのメンバーと相部屋でご利用されたい場合など柔軟にご利用頂けます。どうぞご活用ください。
※ 本パッケージに関する詳しいお問い合わせは上記 JTB までお問い合わせください。より多くの皆様のご参加を心より楽しみに致しております。

PS.
本パッケージをご利用頂くか否かで、私には一切見入りはございませんのでどうぞご理解ください。参加者の皆様に、より「好立地で安全な場所」を提供できないかと、今年初めて JavaOne 参加者の皆様向けに企画した内容です。どなたからもご利用頂けなかった場合は来年はないかもしれませんが、フィードバック等に応じて検討させて頂きたいと思いますので、フィードバックも頂ければ幸いです。

2014年6月5日 at 5:04 PM 1件のコメント

Java Day Tokyo 2014 終了の御礼


2014年 5/22(木)に今年最大の Java イベント Java Day Tokyo 2014 が無事終了しました。当日は、日本全国から多くの Java 開発者の皆様にお越し頂き誠にありがとうございました。昨年を上回る来場者数を記録し、ご参加頂いた全ての皆様に心より御礼申し上げます。

今年の Java Day Tokyo のテーマは、日本オラクル発の「Java SE 8」ローンチ・イベントでした。このイベントに併せて、US から Lambda の開発者を始めとして、多くのエンジニアに来日してもらい、丸一日 Java SE 8 関連セッションで様々な情報を入手して頂いたのではないでしょうか。多くの Java 開発者の皆様にとって今年のイベントが Java SE 8 採用に向けた出発点になって頂ければ誠に幸いです。

また本イベントに併せて、まだ完全ではないながらも日本語版 Java SE 8 API ドキュメントを公開できました。残りの部分につきましては随時対応をしてまいりますので、どうぞご安心頂くと共にご活用ください。

● 日本語版:Java Platform Standard Edition 8 ドキュメント
● OTN の「Java SE API & ドキュメント」サイトから:

● アーカイブ(zip)版も下記から入手可能です。

その他、JDK 8 のリリースノート等も一部日本語化を行いました。
下記リンクも併せてご覧ください。

● JDK 8の新機能
● JDK 8の既知の問題
● JDK 8およびJRE 8でサポートされるロケール
● Oracle JDK 8およびJRE 8認定システムの構成
● Java Platform, Standard Edition 8の名前とバージョン
● Java Mission Control 5.3リリース・ノート
● JDK 8採用ガイド
● JDK 8の互換性ガイド(翻訳中)

最後に、
今年、ご参加頂いた皆様、本当にありがとうございました。来年また Java 開発者の皆様と Java のお祭りができる事を心より楽しみにしております。

私の発表資料「Java SE 8時代のJava EE 7アプリケーション開発」も下記に公開しております。どうぞご参照ください。

また、上記発表中でご覧頂いた WebSocket のデモはここに公開しています。GlassFish v4.0.1 b5 以上でご確認頂けます。また、ソースコードはコチラからご覧頂けます

PS.
今年の夕方のイベントはグダグダになってすいませんでした。来年の夕方のイベントは、今一度仕切り直して、また楽しい夜のイベントを企画し実施したいと思っております。

2014年5月27日 at 2:54 PM コメントをどうぞ

Java Day Tech Night の詳細な内容につきまして



Java Day Tokyo 2014 は早いものでもうあと3日に迫りました。すでに何名かの講演者が来日しておりイベントの準備もいよいよ最終段階に入ってきています。

さて、今日は「Java Day Tech Night」の詳細についてご案内します。

今年の「Java Day Tech Night」は、本場サンフランシスコの JavaOne さながらの BoF として「Ask The Experts」を行いたいと思います。本場 JavaOne では 「Meet the Spec Lead」という BoF セッションがあり、参加者が会場で自ら直接講演者に対して質問を投げかける事ができます。

今回は、その本場 JavaOne の「Meet the Spec Lead」を模して、今年来日した4名の講演者に対して、「Ask The Experts」セッションとして、会場にいらっしゃる皆様から直接ご質問やご意見をお伺いする場を設けたいと考えています。
※ 過去、お昼の時間帯に実施しておりましたが、人気セッションだったため、今年は規模と時間を拡大して、もっと多くの方に ご参加頂き、講演者と直接交流を持って頂ければと考えております。

また、本イベントの UStream 配信も正式に決定しました。関東近郊以外の皆様、もしくはお仕事でどうしてもお越し頂く事ができなかった皆様には、是非 UStream でご覧頂けないでしょうか。
※1: UStream を視聴頂くためには登録が必要です。登録用の URL は別途ご案内致します。
※2: 本 Stream 配信は録画はいたしません。リアルタイムでのみご視聴いただけます。

Twitter のハッシュタグ:#jdt2014_A5

Experts :
* Stuart Marks (Lambda 式の開発者)
* Simon Ritter (Java SE/SE Embedded/JavaFX のエバンジェリスト)
* Stephen Chin (JavaOne の Chair)
* Reza Rahman(Java EE のエバンジェリスト)

通訳:
David Buck

皆様から頂くご質問、ご意見のカテゴリとして下記を考えております。

* オラクルの Java 活動に関する質問、ご意見
 例:世界のコミュニティ活動について教えて欲しい
   日本のコミュニティについてもっと連携して欲しい
   日本のコミュニティに対してヘルプして欲しい。
   Adopt-A-JSR はどうしたら参加できるの?
   世界の何カ国にどの位の頻度で巡っているの?
  提案:
   もっと、海外のエンジニアに日本にきて欲しい。
   ***の部分をもっと改善して欲しい。

* Lambda 式について
 スペックを含む技術的なご質問、ご意見など
 セッション中で疑問に思った事。

* JavaSE/JavaFX/Java Embedded に関連する内容(Lambda 式以外)
 Lambda に関する以外の全てのご質問
 スペックを含む技術的なご質問、ご意見など

* Java EE に関して
 スペックを含む技術的なご質問、ご意見など
 次の Java EE 8 はこのような機能を入れて欲しい。
 
などなど。

皆様がお持ちの疑問や課題、ご意見等を是非我々に直接お届けください。
皆様の貴重なご意見、ご質問が「次の Java をさらに良くするため」の、きっかけになるかも知れません。多くの皆様のご参加とご意見・ご質問を心よりお待ち致しております。

ご意見・質問頂ける方へのご案内:
当日開場の両サイドに、ご質問者用のマイクを2本用意しています。ご質問を頂ける方は、直接マイクが置いてある場所までお越し頂けないでしょうか。またセッションが始まるとすぐに、1番目のカテゴリ「オラクルの Java 活動に関する質問、ご意見」に入りたいと思います。本プログラムが正式に始まる前から両サイドのマイクにお並び頂ければ誠に幸いです。

開場のマイクの置き場所について

2014年5月19日 at 6:32 PM コメントをどうぞ

過去の投稿


ご注意

このエントリは個人の見解であり、所属する会社の公式見解ではありません

JavaOne

カレンダー

2014年12月
« 10月    
1234567
891011121314
15161718192021
22232425262728
293031  

カテゴリー

Twitter

clustermap

ブログ統計情報

  • 578,813 hits

Feeds


フォロー

新しい投稿をメールで受信しましょう。

現在3,867人フォロワーがいます。