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 、そして OSSJMeter が有名ですが、これらは 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 スタイリングを使う、IDEIntelliJNetBeans が良いこと、Java8 をしっかり予習しておこう、何より楽しもう!といった点を挙げていました。

また、LoadUI の開発を通して、開発を支援するために開発した、GuavaFXTestFX を紹介しました。どちらも 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 はこれに XMLJDBCRMI などが加わります。compact3 にはさらに JMX、naming、security、コンパイラ API が加わります。ただし、これらプロファイルに含まれているものでも、java.beans パッケージを参照している API は取り除かれます。

Compact Profile は OpenJDK のソースからビルドすることが可能で、Linux のみをターゲットとしているとのことです。
OpenJDK のソースを hg fclone して、make images profiles を実行することで各プロファイルのイメージがビルドされます。
各イメージは別のクラスファイルが生成されるので、compact1 のイメージに compact2 のクラスファイルを追加する、といったことはできないそうです。

プロファイルを利用するアプリケーションを開発する場合、 javac -profile とするか、javac -bootclasspath でクラスパスを指定します。
また、NetBeans7.4 ではプロファイルが選択できるようになっています。その場合、プロファイルで使用できないクラスを使うと、ソースエディタ上で警告してくれるようになります。

さて、この Compact Profile の配布形態についてですが、 RI と Embedded Compact Profiles という 2 種類のプロダクトがリリースされるとのことです。
前者は文字通り参照実装で、Linux x86 のみをターゲットとしており、サイズもそのままとのことです。
これに対し後者は Oracle の商用プロダクトであり、ARM、PPCx86 に対応し、サイズもより小さくなっているとのことです。組み込み向けに 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 のみをターゲットとし、WindowsMac 向けには 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 で署名必須というのも何だかなあとは思いますが、最近のクライアントアプリ開発は iOSMacWindows など審査を通す必要のあるプラットフォームが増えましたし、牧歌的な時代は終わったのかも知れませんねえ。

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 サポートとかも考えたいね、といった話とかしてましたねえ。

What and How Java Troubleshooters Think: Eight Years of Troubleshooting Java [BOF7862]

アクロクエスト谷本さん勝本さんによる BOF です!

途中何度か詰まってしまったところがあって、見ているこちらもとても緊張しましたw
でも、内容的には実事例を元にした実践的な内容であったので、結構聴講者を引きつけていたと思います。人も結構入っていたし、途中から退席する人も少なかったように見えます。まずまず成功したといっていいのではないでしょうか。お疲れ様でした!

*1:自分のブログでも以前にこのエントリでSmartBear社のツールについて取り上げたことがあります。