JJUG CCC 2016 Springに参加しての感想
2016/05/21 に開催された JJUG CCC 2016 Spring に参加してきました。ちょっと遅くなりましたが参加した各セッションについて感想を簡単にまとめました。
参加したセッション
- 基調講演2： Raspberry Pi with Java
- E-3 Spring Boot で Boot した後に作る Web アプリケーション基盤
- AB-4 Introduction to JShell: The Java REPL Tool
- I-5 JavaデスクトッププログラムをふつーのWindowsプログラムのように配布・実行する方法とPCの動きが重くならないよう気を付けること
- M-6_1 十徳ナイフとしてのGradle
- I-6_2 OpenJDK コミュニティに参加してみよう
- GH-7 Java Puzzlers
基調講演2： Raspberry Pi with Java
Java エバンジェリストである Stephen Chin さんによるキーノートセッション。Stephen さんは Night Hacking Tour というのを行っていて、世界の色んな国をバイクで駆け巡り、Java を使った面白い勉強会を行っていますが、今回日本でそれを行っています。既に岡山や大阪などを回っていますが、今回この JJUG CCC で東京版を行うことになったというものでした。
内容は Raspberry Pi を使って、ファミコンのゲームコンソール (筐体の形はゲームボーイアドバンス風) を作るというもの。ソフトウェア、ハードウェアの両面から様々なハッキングを行ったという内容でとても楽しい内容でした。
ソフトウェア面では Raspberry Pi 上の Java に Java 製 NES エミュレータ halfnes を使用した点が目を引きました。オリジナルは Swing 製でデスクトップ向けでしたが、これを Raspberry Pi 向けに GUI 部分を JavaFX で作り直したとのこと！ X を使わず直接フレームバッファに書き込む JavaFX の利点をアピールしていました。 *1
ボタンの数に対する GPIO の不足を左・右ボタンは同時に押さない点に着目して回避したり、3D プリンタでのヒンジの作成で様々な試行錯誤したりなど、ハードウェア面でのハックの話も面白かったです。
こう言っちゃあれかもしれませんが、Oracle にもまだこういう遊び心たっぷりな方がエバンジェリストとして残っていて良かったなあと思いました。
E-3 Spring Boot で Boot した後に作る Web アプリケーション基盤
エムスリーの吉田さんによる、Spring Boot で構築した Web アプリケーション開発について、開発環境を構築した後の開発方針についてどうしていったかについてのお話でした。
Spring Boot では開発環境構築のお膳立てをしてくれますが、その後は Spring Framework を用いたアプリケーション開発になっていきます。そこで例外処理やトランザクション設計、URL 設計、バッチ処理、設定ファイル、ログ、セキュリティといった、共通的に考慮しないといけないことをどう設計したかを説明してもらいました。
バッチ設計のところなど、所々自分の考えとは違うところはあったものの、参考になる情報が多かったです。実は近々自分も Spring Framework を久々に使うことになりそうなので、Spring については浦島状態になっている自分にはとても助かる内容でした。
AB-4 Introduction to JShell: The Java REPL Tool
Kulla プロジェクトのコミッタになった bitter_fox さん自身による JShell の解説です。今年から就活する点をちょっとアピールしてましたw
JShell でやれることを全体的にとても分かり易く説明していました。他の言語では大体あったものですが、ようやく Java にも来てくれて嬉しいです。今まで自分自身は IntelliJ の Groovy コンソールを使ってこの用途を満たしていましたが。 *2
少し驚いたのが、JShell の開発者に JavaFX Script コンパイラの作者が入っていた点です。JavaFX Script が無くなった後、こういうことをしていたのかあ。
I-5 JavaデスクトッププログラムをふつーのWindowsプログラムのように配布・実行する方法とPCの動きが重くならないよう気を付けること
高橋さんによる、Windows 環境へ javapackager を用いてパッケージングした JavaFX アプリケーションを配布する際に工夫したことを説明するというセッションです。
このセッションで取り上げられていた javapackager については手前味噌ながら自分のブログエントリでも紹介しています。
この javapackager、中々良くできているのですが、上書きインストールができない、インストールディレクトリの指定をさせることができない、など細かい点で足りないところが目に付きます。そこを Wix Toolset 側の設定に手を入れることで乗り切ったという話がとても参考になりました。
javapackager の存在については驚いた人が多かったようで、セッションの最後に沢山質問が出てきたのが印象的でした。やはりこういうものを求めていた人が多かったんでしょうねえ。*3 その割に知られていないというのが残念です。もっと Oracle はこのツールの存在をアピールした方がいいですよー。
M-6_1 十徳ナイフとしてのGradle
grimrose さんによる Gradle についてのショートセッションです。何と立ち見状態になっていて、床にべたっと座って聞く形になっちゃいました。Gradle 本当に注目を浴びてますねえ。
内容としては Gradle 徹底入門を補完するような内容になっていて、Gradle のタスクランナーとしての側面に着目し、日常のタスク処理に Gradle を活用するためのお話になっていました。特にスクリプト実行環境があまり強力ではない Windows 環境での活用を推してましたねえ。
ホットな話題である、Kotlin Gradle についても少し触れましたが、「うーん、これ嬉しいですか？」と聞いたところで場が爆笑で包まれたのが印象的でした。 *4
I-6_2 OpenJDK コミュニティに参加してみよう
OpenJDK のコミッタである久保田さんによる、OpenJDK コミュニティに参加するための最初の一歩について説明するというセッションでした。
OpenJDK のような巨大なプロジェクトになると、参加するのはとても敷居が高い印象がありますが、やはりパッチを送るのが一番良いとのことでした。ML へパッチを送るくらいならば、OCA にサインすればできるようになるようです。
多数あるリポジトリの歩き方、パッチや意見の送り先となる ML の雰囲気など、OpenJDK プロジェクトに参加されている方ならではの話が満載でとても面白かったです。
GH-7 Java Puzzlers
最後はさくらばさん、てらださんのコンビによる、Java Puzzlers のセッションでした。
Java Puzzlers と言えば、Joshua Bloch さんと Neal Gafter さんによる JavaOne の名物セッションでしたが、今や前者は Google 、後者は Microsoft に籍を移しているため *5 、行われなくなっちゃいました。
日本版はさくらばさんとてらださんコンビになりましたが、意図的なのか自然にそうなったのか、てらださんがボケ、さくらばさんがツッコミというスタイルでの進行になっていましたw
内容としては基本的な演算子やクラス、Java8 で加わったラムダ式のコーナーケースについて問うものでした。選択肢式だったこともあり、間違った理解で回答したものもいくつかあったのですが、終わってみたら全問正解は私一人という結果になっちゃいました。(^^ゞ
全問正解ということで、さくらばさん作「Java SE 7/8 速攻入門」を頂いちゃいました。ありがとうございました。
最後に
こういう技術者が集まる場に参加するのは恐らく昨年の CCC Spring 以来だったと思いますが、やはり他のエンジニアの方々と交流すると色々な刺激が得られていいですね。
非常に規模が大きくなって驚いたのですが、これを運営するのも大変だったと思います。JJUG 運営の皆様、本当にご苦労様でした。
Mac上のOpenJDK/OracleJDKはApple実装モジュールへの依存が残っている
はじめに
Mac OS X 向けの Java 実装はかつて Apple 自身が開発、提供していました。ですがそれは 6 で終了し、7 以降は Apple も OpenJDK に参加、OpenJDK 上で OS X 向け実装も開発されるようになり、Oralce から Mac OS X 向け JDK/JRE を提供されるようになっています。
ところが、全てが OpenJDK に移ったわけではなく、一部 Apple が実装、メンテナンスしているモジュールへの依存が残っていることを知り、ちょっと驚いたのでその内容についてまとめてみました。
Yosemite以降の新Look & FeelへのSwingの対応について
これに気付いたきっかけは、Mac OS X の UI デザインが Yosemite で一新されたことです。
Java の GUI ツールキットの 1 つである Swing は、OS の UI ツールキットが提供するコントロールを直接利用せず、Java2D を使って自分でコントロールを描画します。OS の UI ツールキットに似せた見た目にする、システム Look & Feel もありますが、これは自分で描画して似せているだけです。
さて、Mac OS X では Yosemite になって Look & Feel が一新されましたが、Swing については Swing 側が対応しない限り見た目は前のままのはずです。実際、次のスクリーンショットのように Mavericks 以前の Look & Feel のままでした。
最近、家で使っているマシンを新しく Mac mini に変えました。これには El Capitan がプリインストールされているのですが、こちらでは Swing の Look & Feel が Yosemite 以降のそれに変更されていたのです。
Java のアップデートで対応したのかな？と思って、別にある Yosemite 環境のマシンについても Java を最新版にしました。ところが、JRE のバージョンが全く同じなのに、こちらでは古い Look & Feel のままなのです (上 2 つのスクリーンショットの Java バージョン表記を確認してください) 。
これは一体どういうことなのだろうと不思議に思って、調べてみました。すると、OpenJDK の ML に次のようなスレッドがあるのを見つけました。
http://mail.openjdk.java.net/pipermail/swing-dev/2015-September/004855.html
そこでは次のような説明がありました。
The Aqua look and feel is based on the JRS library, which is provided by Apple. As far as I know the Apple provide the new "modern style controls" in the new version of JRS in OS X v10.11. You can ask additional information on java-dev mailing list at apple.com [1]
Mac OS X の Aqua 風 Look & Feel については Apple が提供している JRS と呼ばれるライブラリによって提供されているとのことです。そして OS X 10.11 (つまり El Capitan) では新しい JRS が提供され、その JRS では新しい Look & Feel に対応しているため、El Capitan でだけ Swing の見た目がアップデートされたということになります。
JRSとは何か？
JRS の正式名称は JavaRuntimeSupport になります。実体は以下の場所にありました。
/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaRuntimeSupport.framework/Versions/A/JavaRuntimeSupport
この JRS は OpenJDK には含まれておらず、ソースコードは Apple によってメンテナンス、提供されているとのことです。次の Apple の開発者向け ML にその点を説明するスレッドがありました。
http://lists.apple.com/archives/java-dev/2015/Dec/msg00007.html
これには驚きました。最初に述べたように Java 7 以降の Mac 上の Java 開発は OpenJDK に移行したはずです。それなのに、Apple 側から OS アップデートを通して提供されるモジュールがなければ変わらない部分があったということです。UI の Look & Feel に関わる部分であるため、意匠権絡みなどで移せない事情でもあったのでしょうか？
今後はどうなる？
というわけで Mac 環境における OpenJDK (Oracle JDK) には Apple 実装モジュールへの依存が残っていることが分かりましたが、少し不安なところがあります。というのも、Apple は旧 Apple Java 6 のサポートは El Capitan を最後にすると宣言しているからです。
そのため、JRS のような Apple 提供モジュールの更新も今後行われなくなる可能性があります。OpenJDK 側でもこの状況については Issue が上がっていますが、さてどうなることやら...。
[JDK-8024281] Mac OS X: stop relying on Apple's JavaVM Frameworks - Java Bug System
https://bugs.openjdk.java.net/browse/JDK-8024281
おまけ
旧 Apple Java 6 は El Capitan が最後のサポートバージョンになるとのことですが、その El Capitan 向けインストーラが Apple から提供されています。 *1
ダウンロード - Java for OS X 2015-001
https://support.apple.com/kb/DL1572?locale=ja_JP&viewlocale=ja_JP
このインストーラ、Yosemite 以前のバージョンにも使うことができます。しかもこのインストーラでインストールされる Java 6 には、El Capitan 向けの JRS がバックポートされています。よって、Yosemite にこのインストーラを使って Java 6 をインストールすると、次のように Yosemite でも Swing の Look & Feel が新デザインに変わります！
JSR-377 Desktop|Embedded Application APIなんてのが始まっているようです
最近知ったのですが、 JSR-377 Desktop|Embedded Application API というものがスタートしているそうです。
英語圏でもごく狭い範囲でしか話題になっていないようで、もちろん日本語でこの情報について触れている人は自分の観測範囲では見当たりませんでしたので、ちょっと紹介してみたいと思います。
JSR-377 の Web ページから引用すると、次の API を定めようとしているようです。
* dependency injection via JSR330.
* common application structure.
* application life-cycle.
* localized resources.
* resource injection.
* localized configuration.
* decouple state from UI (binding).
* persistence session state (preferences).
* action management.
* component life-cycle.
* light-weight event bus.
* honor threading concerns (specific to UI toolkit).
* application extensibility via plugins (implies modularity).
要は比較的大規模な GUI アプリケーションを開発する際に、大体いつも作られる機能を共通化してしまおうというものです。アプリケーションフレームワークを作ろうとしているのですね。
実は過去にも JSR-296 Swing Application Framework というものがありました。これは Swing 開発のためのアプリケーションフレームワークを作ろうというもので、確か Java SE 7 に含めることを目標としていたように記憶しています。
ですがその後、Sun が Java の GUI 開発プラットフォームの主軸を Swing から JavaFX に移すという方針転換を行った影響で、この JSR はお蔵入りになってしまいました。
なので、JSR-377 は Swing App Framework のリブート版のように見受けられます。そういう意味でも個人的にとても注目しています。
Spec Lead は Groovy の GUI フレームワークである Griffon の開発者 Andres Almiray さんです。 Expart Group には Hendrik Ebbers さんや Johan Vos さんなど JavaFX 界で有名な方々が名を連ねています。
この JSR で目を引くのが、Swing、JavaFX、SWT といった UI ツールキットを特に限定していない点です。特定のツールキットに依存しない、抽象的な API にすることを目指しているようです。
こういう変に抽象化した API を作ろうとするとうまく行かないことが多いので、個人的には少し引っ掛かります。
ただ、メンバーには JavaFX 系の人が多い (JavaFX でのデータ取得を抽象化するフレームワークである DataFX の開発メンバーが多い) ので、実際には JavaFX 中心で話が進むと見ています。
とは言え、こういうアプリケーションフレームワークができてくると、大規模開発における敷居も低くなりますし、今後に注目していきたいと思っています。
きしださんの文字列連結のやつをCharBufferでやってみる
多分色んな人が既にやっていて何番煎じになっているか分かりませんが、きしだ (id:nowokay / @kis) さんの「StringBuilderを使ったクソコードはどこまで遅いか 」「Java8時代の文字列連結まとめ」について自分もちょっと遊んでみました。
というのも今日の昼飯時に社内でもこの話が話題になって、そこで弊社の某モヒカンより「性能面でセンシティブな場面で String を使うことを考えるな。CharBuffer 使え。」との言葉を賜りましたからです。
と言うわけで以下のコードを試してみました。
public static String charBufferJoin() { CharBuffer buffer = CharBuffer.allocate(7995); buffer.put('['); for (int i = 0; i < strarray.length; ++i) { if (i != 0) { buffer.put(',').put('['); } buffer.put(strarray[i]).put(']'); } buffer.flip(); return buffer.toString(); }
結果は、
charBufferJoin:1261ms stringJoin:2800ms stringJoiner:2135ms streamListJoin3:2362ms streamListParallelJoin3:3677ms stringBuilderJoin:1870ms stringBuilderJoinMem:1652ms stringBuilderFuckingJoin:2480ms
確かに速いっぽい。 *1 前述の某モヒカンのお言葉は正しかったようです。
おしまい。
*1:あと、ぼくのマシン、きしださんのマシンよりかなり遅いっぽい...。
JavaOne参加レポート (9/25)
JavaOne 4 日目となる 9/25 のレポートです。JJUG の JavaOne 報告会の準備でこちらの作業を後回しにしてしまい、こんなに遅い公開となりました。ごめんなさい。
この日に参加したセッションは次の通りです。この日は夜に Oracle Open World と一緒に開催される Appreciatition Event があったので、夕方まででセッションが終わりました。
- In-Database Container for Hadoop: When MapReduce Meets RDBMS [CON9240]
- Java 8 Streams: Lambda in Top Gear [CON7942]
- Java 8 Collections and Concurrency [CON7962]
- Optimizing JavaFX Applications [CON3141]
- Top 10 Web Application Defenses for Java Developers [CON5523]
- The State of Java Web Container Security [CON8016]
JavaFX や Java SE ではとても濃い内容の話を聞けました。また、Hadoop という JavaOne ではちょっと異色のセッションにも参加しています。
In-Database Container for Hadoop: When MapReduce Meets RDBMS [CON9240]
Hadoop についてのセッションです。Oracle では何と Hadoop を Oracle のコンテナ上で動かしてしまおうという試みを行っているようで、そのアーキテクチャ、利用方法についてデモを交えて解説するというものでした。
Hadoop を利用する上で大きな課題がデータの移動です。多くの場合、Hadoop を使って解析したいデータは何らかの別のストレージ (多くはデータベース) に置かれています。
これを Hadoop (HDFS) 側に持ってくる必要がありますが、何せ対象は「ビッグデータ」。移動するだけでも大変ですが、セキュリティ、データの整合性などにも気をつかう必要があり、相当な運用スキルが要求されます。
そこで Oracle が考えたのは、いっそのこと Oracle の上で Hadoop を動かしちゃおう！というものです。
Oracle DB は JVM も動かしていますが、この上で Apache Hadoop を動かします。Oracle の Parallel Query エンジンがデータのパーティショニングやジョブのスケジューリングを行うというアーキテクチャです。
データストレージとしては通常のファイルの他に Oracle 上のテーブルやビューも対象とします。Oracle のテーブルやビューを読み書きするために専用の TableReader、TableWriter クラスを用意しています。ダイレクトに Oracle のテーブル上のデータを読み書きできるので、わざわざデータを移動する必要がないということになります。
MapReduce ジョブの実行方法についてですが、Mapper と Reducer は通常の Hadoop の開発と同じように作ります。この MapReduce ジョブは Java でドライバクラスを作って実行する方法 (通常の Hadoop におけるジョブ実行方法) と、SQL から実行する方法があります。
Java で記述する場合、oracle.sql.hadoop パッケージにある Job クラスを使って、ジョブの実行設定を記述します。Job#setMapOutputKeyDBType("VARCHAR2(10)") とか記述しますw Job#run() の引数に読み込み元のテーブルと出力先のテーブルを指定します。
Java で作ったジョブは Oracle に登録し、Java ストアドプロシージャとして実行することになります。
SQL の場合、SELCT * FROM TABLE (HREDUCE_JP_WORDCOUNT(:RedConf, ... (HMAP_JP_WORDCOUNT(:MapConf, ... という感じで、Map ジョブや Reduce ジョブの結果をテーブルに見立てて SQL を記述します。うまく書けば SQL でデータのパイプラインを組み立てられることになります。
これもやはりストアドプロシージャとして登録して実行することになります。
実際にデモも行ってもらいました。MapReduce を使ってアクセス数を集計するというものです。SQL* Plus から MapReduce ジョブを実行する様はなかなかシュールでしたw
MapReduce タスクが読み込みやすいような形のビューを作って実行させていました。
なかなかすごいのですが、現時点ではプロトタイプのみで製品にはなっていないようです。ですがデータ移動に困っている人は結構多いはずですので、製品化を期待して待っています。
でも高そう。製品化するとなると恐らく Big Data Appliance や Exadata といったアプライアンス製品に載るんでしょうね。
なお、先日行われたJavaOne 2013 サンフランシスコ報告会 TokyoでもLTでこのセッションについてのお話しをしました。当日の発表資料を以下に示しておくのでご参考までに。
Java 8 Streams: Lambda in Top Gear [CON7942]
Brian Goetzさんによる、Stream についてみっちり解説するセッションです。大変人気のあるセッションで、立ち見が発生していました。
Java SE 8 になって導入される Lambda 式ですが、その Lambda 式の導入で最も大きな変化があるのがコレクションの操作です。Stream の導入により、Java でもデータ操作を宣言的に行えるようになります。
Stream はデータセットに対する処理の抽象化です。データ構造ではありません。
無限リストを取り扱うことができ、処理は UNIX のコマンドのようにパイプラインをつなげるような形で処理を行います。
Stream のパイプラインはソース、0かそれ以上の中間操作、終端操作で構成されます。基本的に中間操作を行うメソッドはパイプラインを組み立てるだけで、可能な限り遅延処理されます。パイプラインの実行を行うのは終端操作となります。
Stream<Txn> s1 = txns.stream(); // ソース Stream<Txn> s2 = s1.filter(t -> t.getBuyer().getState().equals(“NY”)); // 中間操作 IntStream s3 = s2.mapToInt(Txn::getPrice); // 中間操作 int sum = s3.sum(); // 終端操作
ソースの生成方法は色々あります。通常はコレクションの stream() メソッドを呼び出して作りますが、IntStream.range() や Files.walk() みたいなのもあります。
このソースによって SIZED、ORDERED、DISTINCT、SORTED といった Stream の性質が決まります。例えば ArrayList だったら SIZED と ORDERED という性質を持ちます。
また、ソースによって Decomposition (ばらしやすさ) が異なり、並列処理に影響します。例えば LinkedList はばらせないので、並列処理の効果がありません。
中間操作の処理は先ほども述べたように遅延されます。また、中間操作はパイプラインの性質に影響を与えます。例えば map() は SIZED を保持しますが、DISTINCT や SORTED の性質は消えます。
そして終端操作がパイプラインを実行することになります。この処理がシーケンシャルもしくはパラレルに実行されることになります。
また注意点として、パイプラインは一度きりの実行で分岐や再利用はできないこと、実行中はソースをいじらないこと、処理はステートレスに行う必要があることを挙げていました。
最後の点についてですが、例えば次のように forEach() の中で外部のコレクションに値を追加するようなことは NG です。こうするとスレッドセーフでなくなり、並列化できなくなります。
List<Person> sellers = new ArrayList<>(); txns.map(Txn::getSeller).forEach(s -> sellers.add(s));
次のように畳み込み処理のために用意されたメソッドを使うようにします。
txn.map(Txn::getSeller).collect(Collectors.toList());
並列処理を行う場合は stream() メソッドの代わりに parallelStream() メソッドを使います。当然のことながら並列化してもしなくても結果が同じになるようにしなければいけません。 *1
また、タスクごとに互いの結果に触れることもできません。
Java SE 7 で導入された Fork/Join フレームワークをベースに作られている *2 ので、分割統治法で処理されます。
最後に並列化の性能について触れていましたが、データセットのサイズを N 、パイプライン処理のコストを Q として、N * Q が高い値になるほど並列化の効果が得られやすいとのことでした。
実データの比較結果を見せてもらいましたが、だいたいレコード数が 10,000 を超えたあたりで逆転していました。
とても濃い内容のセッションでした。仕様策定に関わった人から直接こういう濃い内容の話を聞けるというのはいいですねえ。
Java 8 Collections and Concurrency [CON7962]
Java SE 8 におけるクラスライブラリの細かい改善について解説するセッションです。具体的には JSR-335、JEP-142、155、171、180 についての解説です。
JEP-142 は @Contended というアノテーションを追加し、False Sharing 問題を解決するというものです。
Java でフィールドを複数持つクラスを定義すると、それぞれのフィールドが連続したメモリアドレスに配置されますが、マルチコアの場合、共有していないデータを CPU キャッシュ上の同一ラインで共有してしまうという、False Sharing 問題を発生させることがあります。 *3
そこで新たに加わった @Contended アノテーションを片方のフィールドに付与すると、別々のラインに配置してくれるようになるとのことです。
JEP-155 は並行処理に関する小さなアップデートを集めたものです。以下に概要を列挙します。
- 複数のスレッドから更新され、参照頻度が少ない場合に従来の AtomicLong や AtomicDouble などの代わりに使うことのできる、LongAccumulator や LongAdder といったクラスが追加された。
- Accumulator は汎用的な更新に使う。
- Adder には increment() や add()、sum() といった演算メソッドが用意されている。
- ConcurrentHashMap が強化されている。大きな要素数になった場合のスキャン性能が強化され、バルク操作もできるようになる。よりキャッシュ向きになった。
- ForkJoin の改善。多数のタスクをコミットしたときのスループットが向上している。
- ForkJoin 共有プール。Java SE 8 からは明示的に ForkJoinPool を作らなくても、デフォルトで ForkJoinTask の共有プールが用意されている。
- ReadWriteLock に対する StampedLock というものが新たに追加される。これはいわゆる楽観ロック。
- StampedLock#tryOptimistcRead() して stamp をとり、StampedLock#vaidate() に渡す、という使い方をする。
- CompletionStage というインターフェースが加わる (実装クラスとして CompletableFuture がある) 。これは Deferred オブジェクトに相当するもの。
- stage.thenApply(Lambda 式).thenAccept(Lambda 式).thenRun(Lambda 式) という風に書ける。
JEP-171 はメモリ操作の順序性を保証する機能 (Fence) を追加するというもののようで、sun.misc.Unsafe クラスに読み込み、書き込み、読み書き両方のそれぞれに相当する loadFence()、storeFence()、fullFence() というメソッドが追加されるとのことです。
でも sun パッケージに入っているので表には出てこないということですね。
JEP-180 は HashMap の改善に関するもので、これまではキーのハッシュの衝突が発生した場合、LinkedList に格納していましたが (O(n) オーダーの検索になる) 、8 ではエントリが Comparable の場合に限って、B ツリーに格納するように改善されたようです。
もっとも、良いハッシュアルゴリズムを使うことが一番大事だよと話していました。まあそうですねえ。
JSR-335 はコレクションの拡張です。次のような改善が行われています。
- sort() にデフォルト実装が入る。
- コアクラスの実装がより最適化されている。
- map に computeIfAbsent() が入る！
- これは個人的に嬉しかったです。次のようなことができます。
map.computeIfAbsent(key, k -> new ArrayList()).add(elm)
このような感じで、細かいアップデートについてカバーするというセッションでした。こういう細かい情報は案外得られなかったりするので、とってもありがたかったです。
Optimizing JavaFX Applications [CON3141]
JavaFX のレンダリング処理の詳細について解説するという実にディープな内容のセッションでした。
JavaFX は主に 2 つのスレッドが使われています。1 つは FX アプリケーションスレッド (以下 FX スレッド) 。こちらはアプリケーションの入力イベントや後述の pulse イベントを処理するスレッドです。もう 1 つはレンダースレッドで、こちらはシーングラフの状態をレンダリングする処理のために使われます。
そして pulse についての説明です。pulse とは 16ms おきにタイマーで起動されるイベントで、シーングラフの状態を調べて、どうペイントすべきかを決定する処理を行います。タイマーチェックの際に次の条件を満たしていれば実行されます。
- アニメーションが実行中である
- シーン上で変更が発生している (dirty scenes が存在する、という言い方をしていました)
- 明示的に pulse の実行が要求された
- 前の pulse がまだ実行中ではない
pulse の中では、アニメーションの実行 -> CSS の評価 -> レイアウトの評価 -> コンポーネント境界の更新 -> (前回の pulse の結果発生した) レンダリング完了の待機 -> Scene 上の Node の同期 -> RenderJob の作成、の順で処理が行われます。そして、最後の処理で作った RenderJob をレンダースレッドに渡して、レンダースレッドに描画を行ってもらいます。
なお、JavaFX 2.x では FX スレッドとレンダースレッドの並行性に問題があり、レンダースレッドでの RenderJob の実行が完了しなければ次の pulse が実行されないようになっていました。JavaFX 8 では pulse の途中でレンダリング完了を待つフェーズを挟み込むようにし、より並行性を高めているとのことです。
続いて、ハードウェアアクセラレーションが効いている場合とそうでない場合の違いについての説明に入りました。
Windows では Direct3D を使いますが、その場合、 pulse で作られた RenderJob はレンダースレッドに渡され、レンダースレッドにて paint して D3DSwapChain#present() をコールします。
これに対し、ソフトウェアレンダリングになった場合は、レンダースレッドで paint した後、ピクセルをバッファにコピーして FX スレッドに戻してピクセルを更新します。つまり、D3D の場合と違って描画処理の一部が FX スレッドを使うことになります。
Mac の場合は OpenGL を使いますが、レンダースレッドで paint 後、 FX スレッドに戻して、FX スレッドで OpenGL のコンテキストを使ってテクスチャを描画します。
また、JFXPanel を使って Swing 上に JavaFX のシーングラフを置いた場合、Java2D を使ってシーングラフを描画することになります。この場合はレンダースレッドが AWT の Component#repaint() をコールして、AWT に描画させます。
WebView については、WebKit に対して代理のタイマーを渡しているそうです。このタイマーは常に空のアニメーションを実行しており、JavaScript によるアニメーションをハンドルします。
また、Web ページ上でダーティリージョンが発生した場合、レンダリングキューを作って処理をレンダースレッドに渡しているとのことです。
このような JavaFX の動きについて説明した上で、パフォーマンスの計測方法についての解説を行いました。
PerformanceTracker というクラスが com.sun.javafx.perf パッケージにあります。このクラスの getSceneTracker() メソッドの引数に Scene を渡してインスタンスを作ります。このクラスには getInstantFPS() や getAverageFPS() といった性能測定に必要なメソッドが用意されています。
setOnPulse() や setOnRenderedFrameTask() といった、処理フェーズの合間に処理を挟み込めるようなメソッドも用意されています。
また pulse の状態を見るには PulseLogger というものがあり、-Djavafx.pulseLogger=true を設定することで出力されるようになります。pulse の処理情報、実行時間、カウンタなどが出力されます。
最後に JavaFX ランタイムの挙動を変更するいくつかのオプションを紹介していました。
- Glass Robot。com.sun.glass.ui.Robot クラスがそれで、JavaFX 専用の Robot クラス。JemmyFX が使用している。
- フルスピードモードというものがある。-Djavafx.animation.fullspeed=true を設定すると有効化され、pulse の間の待ち時間がなくなる。
- つまり 60FPS 以上を出すことが可能になります。使うとしたらベンチマークの時くらいでしょうね。
- -Dquantums.norenderjobs=true を設定するとシングルスレッドモードになる。
- GLTrace という OpenGL/EGL API の呼び出し状況をトレースするツールがあり、Linux 版及び MacOSX 版がある。
- openjfx/rt/gltrace にソースがある。
最後に JavaFX におけるプロファイリングについてのアドバイスがあり、JavaFX は多くの処理を GPU に行わせており、また CPU を使う処理も大半は JavaFX ランタイムが処理を行っているため、CPU プロファイリングは余り効果的ではないとのことでした。
このセッションで紹介した PulseLogger などのツールを活用すべし、ということでしょうね。
いや、実に濃いセッションでした。こういう話を聞くと、JavaOne に来て良かったなあと思いますね。
Top 10 Web Application Defenses for Java Developers [CON5523]
OWASP のメンバーの Jim Manico さんによる、Web アプリケーションのセキュリティ対策についてのセッションです。
この方、とにかくノリのいい、楽しい方で、すさまじいマシンガントークで、ノリノリになってまくし立てていました。それを聞いているだけで楽しかったです。
SQL インジェクション、パスワード保存、XSS、HTML サニタイズ、CSRF、暗号化、クリックジャッキング、アクセスコントロールなどについて、防御方法を順に説明していました。
それらの説明に割と共通していたのが、「下手に自分で作り込むよりも、過去の知見が集積された OSS ライブラリを活用するように」という点でした。これはなるほどと感心しました。以下、概要を列挙します。
- SQL インジェクションの防止はパラメータ化。Web アプリケーションがクラックされるトップの原因は「';」をテキストボックスに入力されること。
- パスワードの保存についての注意点。
- パスワードは絶対に文字種を限定しないこと！
- 暗号化する場合、キーはクレデンシャルとは別のストアに置くこと。
- ハッシュ生成は別サービスで行う。
- ソルトを付けること。
- XSS の対策はもちろんエスケープだけど、エスケープは色んな種類があって大変。そこで OWASP Java Encoder Project がお勧め。コンテキスト別に必要な関数を提供しており、パフォーマンスもとても良い。
- HTML のサニタイズは、最近だとリッチテキストエディタを用意する必要もあったりして、一概に全てサニタイズできない。そこで OWASP HTML Sanitizer Project がお勧め。許可するタグだけを設定してサニタイズができるようになる。
- CSRF 対策。
- クリックジャッキング。
- iframe を透明化して、別 Web サイトを被せて誤操作させる手口。
- X-FRAME-OPTIONS に SAMEORIGIN を設定して対策する。
- アクセスコントロール。
- 自分で認証認可のロジックを作り込むと、バグがあったときに大変。
- Apache Shiro のようなライブラリを活用しよう。
- Certificate Pinning (証明書のピン留め) 。
- 偽物の CA 対策。
- 詳しくは Pinning Cheat Sheet を見てね。
このような感じで、結構いいまとめでした。なによりセッション全体が楽しかったですねえ。あんな風に楽しいプレゼンができるようになりたいなあ。
The State of Java Web Container Security [CON8016]
これはパネルディスカッションでした。今後 Java EE コンテナに対して、どのようなセキュリティ面での対策が加わるようになるといいのか、について議論するものです。
正直こういうフリーディスカッションの形式だと、自分の英語力では少し厳しかったです。(>_<)
次のような話が話題に挙がりました。
- CSRF 対策。
- HTTP パラメータ汚染。
- セキュリティ制約。
- 今は URL パターンのみだよね。
- ブラウザに指示する HTTP ヘッダ (Strict-Transport=security とか X-Frame-Options とか) を扱えるようにすべきでは？
- 認証認可。
私が聞き取れたのは大体こんなところです。(^^;;
確かにもう少し JavaEE レベルでこのあたりの対策は追加していって欲しいかな、とは思っています。
JavaOne報告会でJavaFXについての発表＆LTを行ってきました
10/19 に実施されたJavaOne 2013 サンフランシスコ報告会 Tokyoにて、JavaFXのアップデートについての発表とLTを行ってきました。
当日のJavaFXアップデートの資料は以下の通りです。
JavaOne2013報告会 JavaFX Update from Takashi Aoe
JavaOne初参加の身でありながら、例年は櫻庭さんが担当されているポジションを引き継ぐことになったので、とても緊張しました。
自分の前に寺田さん、大山さん、櫻庭さんが発表がありました。3人の発表で場が大盛り上がりした状態で自分の発表に入ったのですが、自分の発表になると雰囲気がしーんとした感じになってしまったので、「うわ、これは失敗かなあ...」とショックを受けたのですが、後から聞いた話だと結構皆さんそれなりに楽しんで聞いて頂けたようで、ほっとしています。
そうは言ってもこのような大きな場で長丁場の発表をするのにはまだまだ修行が必要だと言うことがよーく分かりました。精進します。
本編のJavaFXアップデートに続いて、LTでもお話しをしてきました。こちらはJavaOneではちょっと珍しい感じのHadoopのセッションについてです。
JavaFXの方は真面目な感じで行ったので、こちらはちょっとくだけた感じにしました。
発表資料は次の通りです。
JavaOne2013報告会 LT資料 Hadoopの話を聞いてきた from Takashi Aoe
今のところSlideShareでのページビューはLTの方がちょっと上ですね。何だかんだ言ってHadoopは注目ネタですかね。
さて、ブログの方のJavaOne報告もまだ半分ほど残っていますね。こちらも早めにアップします。(^^;;
JavaOne参加レポート (9/24)
JavaOne 3 日目となる 9/24 のレポートです。この日に参加したセッションは以下の通りです。
- Securing Java in the Server Room [CON3636]
- Ten Man-Years of JavaFX: Real-World Project Experiences [CON2670]
- JDK 8 Compact Profiles for Embedded and Oracle ADF Mobile on iOS Devices [CON3736]
- Java Persistence 2.1 [CON6700]
- Dissecting Java Malware [CON5593]
- Jersey 2 MVC in Action [BOF5548]
- Money and Currency in Java: Best Practices, Libraries, and JSR 354 [BOF5267]
- What and How Java Troubleshooters Think: Eight Years of Troubleshooting Java [BOF7862]
この日はセキュリティ系のセッションを 2 つ取りました。今年の JavaOne はセキュリティ系のセッションが多いように思われます。やはりここ最近セキュリティ関連で問題が色々起きたためでしょうか。
Securing Java in the Server Room [CON3636]
IBM UK の方 (IMB Java SE 8 のテクニカルリードだそうです) による、サーバーサイドアプリケーションにおけるセキュリティについてのセッションでした。
サーバーサイドアプリケーションは複数のユーザーのために 1 つのタスクをこなし、様々なクライアントアプリえーションやバックエンドシステムにつながるという特徴があります。ビジネス的に価値があるものを扱っていることが多く、様々なデータが行き交うため、アタッカーの標的になりやすいです。
そのためには計画、開発、運用それぞれのフェーズに置いて計画、対策を行うことが重要であるとのことでした。
つまり、要件定義の段階で分析を行い、開発においてはコード、ライブラリ管理や規約整備をきちんと行い、その上で運用するプラットフォームにおいて各種セキュリティ対策を行う、とライフサイクル全体で取り組むべきであるということです。
また、ウォッチすべき情報源としては CVE や NVD、OWASP、Vender Security Bulletins を紹介していました。
クライアント、サーバー、DB で構成されるシンプルなアーキテクチャを例に、レイヤ別に注意すべき点を次のように説明していました。
- プラットフォーム
- 設定の誤りによって脆弱性を作ってしまう可能性がある。
- ユーザーグループの設定の誤りやポートの割り当てなど。
- Java プラットフォーム
- API を正しく使うこと。
- セキュリティ原則に従ったコーディングを行うこと。リフレクションには注意を払って。
- ミドルウェアとアプリケーション
- ミドルウェアのコンセプトに照らし合わせた正しい使い方を。
- データアクセスへの認証、認可をアプリケーションレイヤで行っている場合は要注意。
- ユーザーセッション
- Unit of Work の範囲内にきちんとデータを保護すること。
- アイデンティティ情報をシェアするときはきちんと保護すること。
- クライアントとのインターフェース
- データ交換には気を遣うこと
- cryptographic のテクニックは色々問題がある。
- データベース
- ビジネス上の要件に照らし合わせて、適切なアクセス制御を行うこと。
- DB の外にも (ファイルなど) データを置くとリスクが増大する。
- システム
- syslog に出力する内容には注意。
- システム固有のツールを利用する場合は注意すること。
割と一般論的な内容でしたが、良くまとまっていたと思います。最後に IBM AppScan という製品を紹介していました。
Ten Man-Years of JavaFX: Real-World Project Experiences [CON2670]
「10 人年の JavaFX 開発！」というなかなか刺激的なタイトルです。
リッチクライアントのテストツールなどを開発、販売している SmartBear 社の方によるセッションです。 *1
LoadUIという JavaFX で開発した負荷テストツールの開発を通して、JavaFX の実開発を通して学んだ JavaFX の良さ、開発上の注意点、工夫したことについて紹介するというとても実践的な内容でした。
先にも挙げたように LoadUI は負荷テストツールです。負荷テストツールと言えば古くからある LoadRunner 、そして OSS の JMeter が有名ですが、これらは UI がとても醜いため、新たに負荷テストツールを開発することにしたとのことです。
LoadUI のインターフェースは以下の写真のようにど派手なものとなっています。
画面内のキャンバスに表示されているボックスが JMeter で言えば左側のツリーに表示されるオブジェクトに相当し、ボックス同士をワイヤリングしてワークフローを作っていきます。ワークフローが視覚的に分かり易いのが特徴です。何よりかっこいいので使っていて楽しそうですね。
最初のバージョンは JavaFX1 で構築しました。JavFX を選んだ理由としては、Illustrator で作成したコンセプトデザインを JavaFX ならば忠実に再現可能だったからだそうです (Swing では難しかった) 。
しかし、JavaFX2 での突然の方針転換。SmartBear 社の CTO が直々に Oracle に EOL を延ばしてくれ！と頼んだそうです。でも答えは「No.」...。ただランタイムの配布は 2013 年 3 月までに延ばしてもらい、2013 年 4 月に JavaFX2 へのマイグレーションを完了、というぎりぎりのタイミングで乗り切ったそうです！
JavaFX1 から 2 への移行は9ヶ月で行ったそうです。ソースコード量は 41K 行から 32 K 行に減りましたが、リライトの必要な部分が多かったとのことです。性能は 2 にすることで大幅に向上したようです。
JavaFX2 の良さとして、JavaFX1 で存在した、IDE サポートがプア、デバッグしにくい、コントロールの種類が少ないという弱点が解消され、FXML によって MVC/MVP アーキテクチャを取れるという利点が加わった点を挙げていました。
ただ、プラットフォーム別に微妙に異なる問題があったり、Bindings.bindBidirectional() / bindContent() が弱参照である点がドキュメント化されていないという落とし穴にはまったとのことです。
JavaFX2 実開発を行った上で学んだ Tips として、全プラットフォームでテストすること、CSS、FXMLをよく学ぶこと、ビットマップは極力避けてなるべく CSS スタイリングを使う、IDE は IntelliJ か NetBeans が良いこと、Java8 をしっかり予習しておこう、何より楽しもう！といった点を挙げていました。
また、LoadUI の開発を通して、開発を支援するために開発した、GuavaFX、TestFX を紹介しました。どちらも OSS で公開しています。
GuavaFX は Goole Guava にインスパイアされた ObservableList を拡張するライブラリです。transfrom、filter、concat といった機能を備えています。キャンバスにドロップしたオブジェクトをまとめてバインディングするのに利用しているようです。JavaFX8 では GuavaFX に備わっている機能がいくつか実装されており、将来的にはこのライブラリが不要になることを望んでいるとのことです。
TestFX は文字通り JavaFX アプリケーションの自動 UI テストを行うためのツールです。OpenJFX では似たようなものとして JemmyFX というツールが開発されていますが、JemmyFX は複雑で冗長であったため、別に開発したとのことです。
JUnit のテストコード上に rightClick("#desktop").moveMouseTo("New").click("Text Documents")... という感じで流れるようにテストする動作を記述できるようになっており、なるほどこれはとても使い易そうだと思いました。
このような感じで本格的なプロジェクトを通しての体験談であったため、非常に聞き応えがあり、学ぶことの多いセッションでした。
JDK 8 Compact Profiles for Embedded and Oracle ADF Mobile on iOS Devices [CON3736]
JavaOne を通して自分が聞いた唯一の Embedded のセッションです。タイトルに iOS と入っていますがこれは完全に釣りで、内容の大部分が JDK8 Compact Profile についての解説でした。
Java SE 8 Compact Profiles とは JDK8 に新たに含まれる小さなランタイムで、Java SE のサブセットとなります。
Java ME/ CDC Converged productに基づいており、ランタイムの小さい順に compact1 / 2/ 3 の 3 種類があります。それとは別に UI スタックとして JavaFX が選択できるようになっています。
compac1 は最も小さく、CDC からの移行に最適で、compact2 はこれに XML、JDBC、RMI などが加わります。compact3 にはさらに JMX、naming、security、コンパイラ API が加わります。ただし、これらプロファイルに含まれているものでも、java.beans パッケージを参照している API は取り除かれます。
Compact Profile は OpenJDK のソースからビルドすることが可能で、Linux のみをターゲットとしているとのことです。
OpenJDK のソースを hg fclone して、make images profiles を実行することで各プロファイルのイメージがビルドされます。
各イメージは別のクラスファイルが生成されるので、compact1 のイメージに compact2 のクラスファイルを追加する、といったことはできないそうです。
プロファイルを利用するアプリケーションを開発する場合、 javac -profile
また、NetBeans7.4 ではプロファイルが選択できるようになっています。その場合、プロファイルで使用できないクラスを使うと、ソースエディタ上で警告してくれるようになります。
さて、この Compact Profile の配布形態についてですが、 RI と Embedded Compact Profiles という 2 種類のプロダクトがリリースされるとのことです。
前者は文字通り参照実装で、Linux x86 のみをターゲットとしており、サイズもそのままとのことです。
これに対し後者は Oracle の商用プロダクトであり、ARM、PPC、x86 に対応し、サイズもより小さくなっているとのことです。組み込み向けに jrecreate というツールも同梱されており、アプリに JRE ごと同梱したい場合などに、必要なものだけを含めたランタイムを生成できるようにしているようです。
Embedded Profiles にはオプショナルコンポーネントとして JavaFX やセキュリティコンポーネントを選べます。
JavaFX は、WebView と MediaView がまだ使えないとのことです。また FXML は Compact2 以上が必要です。JavaFX を追加するとサイズが 10MB 程増え、全体のサイズが 18MB になります。でも仮に Swing/AWT だとこれが 52MB になっちゃうそうです。
また、Swing だと X が必要ですが、JavaFX の場合は直接 OpenGL のライブラリを使うので不要みたいなことを言っていました。
こういった Compact Profile のユースケースとして、キオスク端末やホームゲートウェイ、ETC 的なシステムなどを挙げていました。まさに今回のキーノートでも強調していた IoT 的な分野に関わってきますねえ。
最後にちょっとだけ ADF Mobile とその iOS 実装についての話がありました。Cordova ベースの iOS アプリ部分が VMChannel を通して Compact2 Profile の JVM と通信するというアーキテクチャになっているようです。
現在は Linux のみをターゲットとし、Windows や Mac 向けには Compact Profile の提供はありませんが、Mac AppStore や Windows Store 向けにあった方が良いのかも知れないと話していました。
こんな感じで iOS 云々は完全に釣りでしたが、ほとんど知らなかった Compacto Profile についての情報を収集できたので、まあ良かったかなと思いました。
Java Persistence 2.1 [CON6700]
Linda DeMichiel さんによる JPA2.1 についての解説です。スペックリード本人に解説してもらうというのは JavaOne に参加した甲斐がありますねえ。
JPA2.1 では DB のベンダー関数サポート、Criteria Query でのバルク update、delete サポート、コンバータ、ネイティブクエリの強化などがありますが、今回は Entity Graph 、ストアドプロシージャサポート、スキーマ生成機能の強化の 3 点について詳しく解説してもらいました。
Entity Graph は、エンティティの関連をフェッチする新しい機能です。エンティティ関連のグラフ構造を見て、メタデータを定義することでフェッチを行えるようにするというものです。
例えば、以下の図のようにエンティティの関連の内、赤い部分だけフェッチしたい、というような複雑なフェッチを行う場合に使います。
EntityGrapsh クラスのインスタンスにたどりたいグラフの属性を指定し、そのインスタンスをクエリに対してヒントとして渡すような使い方をします。余りツリーが深いと大変なので、サブグラフを切り出してまとめるようなこともできます。
中々面白い機能だとは思いましたが、使いこなせる人は少なそうだなあとも思いました。そもそも DB からレコードをフェッチする際にグラフ構造を意識してデータを取ってこようという人が果たしてどれ位いるのだろうか？ 少なくとも SIer の現場ではなさそうだなあ。(苦笑)
ストアドサポートは、ストアドの実行と永続化プロバイダへのストアドの登録をサポートしています。
ネイティブクエリと同様、アノテーションでの定義と動的に組み立てての実行の両方が可能です。
結果は INOUT、OUT パラメータや ResultSet のマッピング (ネイティブクエリの場合と同じ) 、executeUpdate() の返値で受け取ります。
スキーマ生成については、インデックスやデフォルト値などの指定ができるようになります。また、FK などの制約も掛けるかどうかを指定できるようになります。これらはメタアノテーションとして用意されています。
また DDL もファイルとしてはき出せるようになります。
ここまでできるようになれば、Java コード側に設定を集約することが可能になりますね。地味ながらもいい進歩だと思いました。
今後についてですが、EE8 にアサイン予定で、現在リクエストを受付中ですよとのことです。
Dissecting Java Malware [CON5593]
今年の Java はセキュリティ面での話題がとても多かったですが、その Java で作られたマルウェアがどのように作られているのか、についてを解説するセッションでした。
Java はブラウザプラグイン経由で起動する場合、SecurityManager を起動します。マルウェアはこれをバイパスすることを狙います。パラメータをチェックしていないネイティブメソッドやプログラムのバグを突いてきます。
最近は Exploits as a Service なんて言葉も出てきているようで、エクスプロイトツールは様々な場所で公開されているようです。urlquery.net ではマルウェアの危険性がある URL がリストアップされているので、参考になるとのことです。
マルウェアは解析を困難にするために様々な工夫をしています (これを Obfucation と呼びます) 。難読化、実行時に定数プールをデコード、決して使わない変数を紛れ込ませてスタックをスクランブルする、といったテクニックを使ってきます。
また、Java のソースとしては戻り値だけが異なるオーバーロードメソッドは NG なのですが、バイトコードとしては許されます。これも obfucation に良く使われるそうです。
ただ、どんなマルウェアは JVM の仕様には従う必要があるので、JVM 上でのコントロールフローを視覚化して解析しているそうです。(そのようなツールとして IDA を紹介していました)
そして、いくつかのマルウェア分析例についての解説がありました。
シリアライズしたオブジェクトを JAR に置く、文字列をわざと StringBuilder 組み立てにして本来の文字列を隠す (RMI 接続のデフォルト名を隠していました) 、null 同士の比較をして絶対に通らないコントロールフローを作る、GIF にデータを紛れ込ませる、といった手段を紹介していました。
ちょっと難しい内容でしたが、実に興味深かったです。
で、こういったマルウェアに対する JRE 側の対策ですが、Java SE 7u25 以降では、コントロールパネルのセキュリティスライダが「高」より上しかなくなり、未署名の Applet は警告ダイアログを出す、古い JRE では動かないようにする、という変更が行われました。
また、古い JRE を除去するツールも用意したとのことです (現在は Windows 用のみ) 。
Applet、Web Start で署名必須にした理由としては、攻撃者にツールとして Java を選択する意欲を低下させる狙いがあったとのことです。
サンドボックス上で動く Java で署名必須というのも何だかなあとは思いますが、最近のクライアントアプリ開発は iOS や Mac、Windows など審査を通す必要のあるプラットフォームが増えましたし、牧歌的な時代は終わったのかも知れませんねえ。
Jersey 2 MVC in Action [BOF5548]
JAX-RS の参照実装である Jersey には、HTML Web アプリケーションを開発するためのちょっとした MVC フレームワークが付いています。Java EE 7 に対応した Jersey2 の MVC フレームワークの新機能について解説するセッションです。Jersey MVC は自分の仕事でも使っていることもあり、とても楽しみにしていたセッションでした。
Jersey2 では MVC フレームワークは別モジュールとなり、基本となる jersey-mvc 、Bean Validation と統合する jersey-mvc-bean-validation 、そしてテンプレートエンジン別に jersey-mvc-jsp / freemarker / mestache モジュールが用意されています。
新機能としては Bean Validation との統合、テンプレートアノテーションの追加、テンプレートエンジンとして FreeMarker と Mustache サポートの追加、が挙げられます。
テンプレートエンジンに Java の世界ではおなじみの FreeMarker に加え、Mustache が追加されたのは驚きました。Mustache はどちらかというと JavaScript の世界でよく使われているテンプレートというイメージがありましたが、Java の世界でも人気が出てきているのでしょうか。
テンプレートについてはこれまでの返値として Viewable オブジェクトを返す方法に加え、@Template アノテーションでテンプレートを指定する方法が加わりました。アノテーションを使った場合はエンティティだけをリターンすれば良くなります (HTML 以外のコンテンツタイプにも一緒に対応できますね) 。
さらに、@ErrorTemplate アノテーションもあり、例外が投げられた場合のテンプレートをしていできます。こうすることでエラー時の分岐も楽に対応できるようになりますね。
これだけでも Jersey2 に移行したいと思いました。
続いてテンプレートの利用についての説明があり、JSP では、コンテキスト変数 it を経由してモデルにアクセスしますが、FreeMarker では model という名称の変数に、Mustache では直接プロパティにアクセスする形式になるとのことです。
また、BeanValidation のエラーメッセージもテンプレートに渡されるようです。
カスタムで好きなテンプレートエンジンを使いたい場合は TemplateProcessor を実装します。割と簡単に実装できそうです。
Bean Validation との統合については、リソースクラスのメソッドパラメータ、フィールド、プロパティに対して Bean Validation の制約アノテーションが付与できるようになります (コンストラクタだけ無理) 。バリデーションエラーは ConstraintViolationException が送出されるので、これに対する ExceptionMapper を用意することになります。
@ErrorTemplate アノテーションを使った場合、List
以前、自分のブログでも以下のエントリで Jersey の MVC 機能を取り上げましたが、Jersey2 では足りないところが結構補われてきたと思いました。これくらいの機能があれば、もう Struts1 はいらないですね！
JAX-RSはHTML Webアプリケーションを開発するのに充分なフレームワークであるか？
http://d.hatena.ne.jp/aoe-tk/20130317/1363527825
Money and Currency in Java: Best Practices, Libraries, and JSR 354 [BOF5267]
JSR 354: Money and Currency API についてのセッションです。スピーカーは Date Time API のセッションも行っていた Stephen Colebourne と、スペックリードである Anatole Tresch さんでした。
Money はとっても大切なドメイン上の概念であるのに、JDK8 になってもまだ何のサポートも入っていないとの問いかけで始まりました。
一方、Currency については既に JDK に入っています。イミュータブルで、ISO 4217 の貨幣コードに対応しています。JDK7 ではオーバーライドが可能になり、JDK8 は貨幣の変更日もサポートできるようになるといった強化がされています。
この Currency クラスは使えるならば使うようにし、文字列を使うことは避けよう！とのことです。
そして Money ですが、これは Amount + Currency の概念を表すものです。これまで金額を扱う場合は BigDecimal を使うか、Joda-Money や Tom Gibara 氏作成の Money ライブラリを利用していました。JSR-354 はこれらライブラリをベースにした標準になるものです。
JDK9 をターゲットに仕様策定を進めており、貨幣のサポート、丸め処理など最小限の演算、貨幣変換、フォーマットなどをサポートします。
登場するクラス群ですが、Stephen Colebourne 氏が参加しているためか、細かいクラスが色々出てきますw
旧 Currency に近い貨幣を表すクラスである MoneyCurrency、金額を表し、計算に必要なメソッドを備えた Money、フォーマッティングを担当する Formatting、貨幣の変換を行う Conversion などがあります。
ヒストリカルなデータにアクセスしたり、リージョンを扱えたりするような拡張も行えるようにするそうです。
まだ仕様策定中であるということもあり、解説は早めに切り上げて、ディスカッションを行う時間を取っていました。JDBC サポートとかも考えたいね、といった話とかしてましたねえ。
