JPQL速かった！〜JPAクエリ表現ごとのパフォーマンス比較 その2

前エントリで、NativeQuery・JPQL・CriteriaAPIのどれが一番速いのかパフォーマンス比較を行い、NativeQuery悪くないじゃん、と結論づけました。そして、JavaEE AdventCalendar 2013を取りまとめて頂いた@megascusさんや、このネタを書く発端となった@yoshioteradaさんを始めとする多くの方々にコメントを頂きました。ありがとうございました。


その中で、JPQLをNamedQueryで宣言しておくと、起動時にプリコンパイルされるのでパフォーマンスが向上する、との情報を頂いたので、再実験してみました。


今回使用したソースはこちら


前回との差分を簡単に振り返っておくと、まず、JPQL文をfindProductという名前をつけて、EntityクラスにNamedQueryとして宣言しました。

@Entity
@Table(name="product")
@NamedQuery(name="findProduct", query="select p from Product p where p.id = :id")
public class Product {

次に、JPQLの実行部分を、このNamedQueryを呼び出すように変更しました。

// List<Product> productsJPQL = em.createQuery("select p from Product p where p.id = " + r.nextInt(100000)).getResultList();

Query query = em.createNamedQuery("findProduct");
query.setParameter("id", r.nextInt(100000));
List<Product> productsJPQL = (List<Product>)query.getResultList();


そして、気になる実験結果は下記の通り。前回と同様5回実行した平均です。

クエリ NamedQuery（ミリ秒） 非NamedQuery（前回の記録）
Native Query 436 421
JPQL 70 1232
Criteria API 600 804
Entity 34 34

あらまぁ…


なお、Persistence.xmlに下記オプションを追加して、実行されたSQLをログに出力してみました。

<property name="eclipselink.logging.level.sql" value="FINE"/>

すると、EntityとJPQLではSQLは発行されていないようでログにはなにも出ず、L1キャッシュに乗っているインスタンスを取ってきているようでした。また、NativeQueryとCriteriaAPIでは下記の通りにログが出ており、SQLが発行されていることが確認できます。

// NativeQuery
[EL Fine]: sql: 2013-01-03 15:13:31.449--ServerSession(570159399)--Connection(296362180)--select * from product where id = 36569

// Criteria API
[EL Fine]: sql: 2013-01-03 15:13:31.496--ServerSession(570159399)--Connection(296362180)--SELECT ID, NAME FROM product WHERE (ID = ?)
	bind => [1 parameter bound]


というわけで、JPQL速いです！JPQLを使いましょー！　…と言いたいところなのですが、ここでふと思うわけです。"DBから取ってくるのと、L1キャッシュから取ってきてる結果を比較して、クエリのパフォーマンス比較になってるのか？”と。


そこで、キャッシュから引いてこれないように、クエリを次のように変えてみました。

@NamedQuery(name="findProducts", query="select p from Product p where p.id > :lowerId and p.id < :upperId")

範囲指定すれば、キャッシュからインスタンスを指定して取ってこれはしないだろう、という目論みです。SQLログを確認すると、確かにこれならJPQLでもDBに対してクエリが発行されていました。

ソースはこちら。
そして、気になる結果は…

クエリ 時間（ミリ秒）
Native Query 2734
JPQL 1929

おお！やはり、JPQL速かった！！


まとめです。
JPAでは、JPQLをNamedQueryにして、起動時にプリコンパイルさせておくのが、速いです。
JPQLにしておくと、JPAの良いところである、永続化装置が何であるかを気にせずに良いという所を活かせるので、一石二鳥ですね。プロジェクトが許すのであれば、JPQLの導入を検討しましょう！


（1/14追記）
さらにご指摘を頂き、

  • NativeQueryもNamedNativeQueryに
  • NativeQueryにバインド変数を使用する

の2点を、考慮して実施してみました。

@NamedNativeQuery(name="findProductsByNative", query="select * from product where id > ?lowerId and id < ?upperId")

ソースはこちら。


結果は…

クエリ 時間（ミリ秒）
Native Query 2335
JPQL 1808


NativeQueryで多少の改良が見られました！
ただ、差はそこまで大きくなくなってきたので、導入しやすい方を使用すれば、そこまで問題にはならなそうです。
ご指摘、ありがとうございました！

NativeQueryじゃだめ？〜JPAクエリ表現ごとのパフォーマンス比較

このエントリはJavaEE Advent Calendar 2012の20日目です。昨日は@den2snさんのJavaを知らない世代が今からはじめるJavaEE開発でした。明日は@javaflavorさんです。

先月、岡山を訪れた時、Javaエバンジェリストである寺田さん（@yoshioterada)に「今仕事でやってるプロジェクトにJPAを導入したんですが、JPQLになじめなくって、素のSQLをNative Queryで投げてるんです。」という話をしたら、「Native Queryはパフォーマンス的に良くなかったはず…」との情報を頂きました。それが本当なら、今のプロジェクトが危ない！正確に言うと、今のプロジェクトにJPAを持ち込んだ自分の身が危ない！
ということで今回は、JPAに用意されている、Native Query、JPQL、criteria API 、それぞれのAPIのパフォーマンスを比較してみることにしました。

まず、それぞれの復習です。

  • Native Query
    • SQLを文字列で記述し、そのままDBに渡す方法
    • 長所：新しいことを覚える必要がないこと、Oracle関数のようなDB依存のクエリも投げられること。
    • 短所：JPAの意義であるデータ永続化装置が何かを気にしなくて良い、という精神をガン無視してること。DBをOracleからMySQLに変えよう（予算的な理由で）、とかになった時に、死にます（工数的な理由で）。
List<Product> products = em.createNativeQuery("select * from product where id = 100").getResultList();
  • JPQL
    • JPAはNativeQueryよりもこちら推し。SQLによく似た、JPQLという文を文字列で記述し、内部でSQLに変換してもらってクエリを投げる方法
    • 長所短所は、NativeQueryの全く逆。別の層の実装が何でも良い、というのは、Javaの思想に一致します。Write once, run anywhere。…ちょっと違うか。
List<Product> products = em.createQuery("select p from product p where p.id = 100").getResultList();
  • Criteria API
    • JPQLは所詮文字列のため、スペルミスがあった場合、実行時まで気づきません。この問題に対応するため、型付け言語Javaの長所を生かして、メソッドチェインでクエリを組み立てます。
    • 長所は、スペルミス等の構文異常をコンパイル時に気づけること。
    • 短所は、感覚的でないこと…。
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Product> cq = cb.createQuery(Product.class);
Root<Product> r = cq.from(Product.class);
cq.select(r).where(cb.equal(r.get("id"), "100"));
List<Product> products = em.createQuery(cq).getResultList();
  • Entity直接指定（おまけ）
    • これぐらい簡単なクエリなら、Entityで直接指定して取ってくることも可能です。
Product product = em.find(Product.class, 100);

では、実験です。

今回DBには、軽量JavaDBであるH2を使います。使い方は簡単。zipを落としてきて、h2-xxx.jarにクラスパスを通すだけ。今回は使用したのはバージョン1.3.170です。
続いて、JPAの実装には、RIであるeclipseLinkを使います。使用バージョンは2.4.1。zipをDLして、jlib配下にあるeclipselink.jarと、jlib/jpa配下にあるjavax.persistence_2.0.4.v201112161009.jarにクラスパスを通します。
ソースはこちら。
実験では10万件のデータをDBに投入しておき、ランダムな1件を引いてくることを1000回ずつ、各クエリごとに行います。それを5回実行した平均の結果がこれ。

クエリ 時間（ミリ秒）
Native Query 421
JPQL 1232
Criteria API 804
Entity 34

NativeQueryを基準とすると、Criteria APIはその2倍、JPQLは3倍の時間がかかりました。Entityでの指定はどれよりもダントツ速い結果になりました。
おそらく、NativeQueryはそのままDBに渡しているだけに対して、JPQLはJPQL文のパース・SQL文の構築・実行、Criteriaはパースが不要でSQLの構築・実行のみ、これがそのまま結果に出ているのだと思われます。Entityが異様に速いのはなぜなんだ…。

（追記）Entityの取得が速いのは、persistした後インスタンスはすぐにGCされるわけではない（いつGCされるかはわからない）のでL1キャッシュに入るので、実際にDBを探索しているのではなく、ヒープに乗っているインスタンスへの参照が返されているだけだからでは、とのご指摘を頂きました。megascusさん、ありがとうございます。

今回は最も単純なクエリでしか実験しなかったため、結果的にはNativeQueryでも問題ない結果になってしまい、寺田さんの真意はわからずじまいでしたが、

  • テーブル結合した場合
  • Prepared Statementにして、文キャッシュを効かせた場合
  • EclipseLinkでなく、Hibernateなど、別の実装の場合

などなど、どんな場面でどんな結果になるのか、機会があればこれらも試してみたい所です。

（余談）　今回DBにH2を使ったのは、直前にjUnit実践入門で読んでいたためです。12章に紹介があって、設定によって、OracleのフリやPostgresのフリをさせられますし、インメモリDBとしても動かせるのでスローテストの解消にも使えそうです。H2を探ってみるのも面白そうです！



【補足】次エントリで追加実験を行い、JPQL遅くない！という結果になったので、合わせてご覧下さい！

岡山Javaユーザ会勉強会で、LTデビューしてきました

11/3に岡山県立図書館で行われた、第4回岡山Javaユーザ会勉強会に参加してきました。


岡山にはJavaに限らず多くのコミュニティが存在し、年末には合同勉強会も行われるらしく、岡山のエンジニアの盛り上がりとコミュ二ティを越えたエンジニア同士のつながりの強さをひしひしと感じました。さすが大都会！


また、今回、岡山Javaユーザ会会長の@zephiransasさんに誘って頂き、LTをやらせて頂いて、スピーカーデビューを果たしました！15分の枠で自分が何分しゃべったのか全然把握していないぐらい緊張していた訳ですが、ちゃんとしゃべれていたのでしょうか。。次回はもうちょっと地に足つけてしゃべりたいと思いますw


以下、勉強会のまとめです。

  • JavaOne 2012 サンフランシスコ・最新アップデート（寺田佳央さん　@yoshioterada）
    • Keynoteで発表された内容を中心に、最新情報のアップデートがされました。
    • アットホームな場の雰囲気のせいか、「これ、twitterとかに書かないで下さいよ！」な話がたくさん飛び出しましたw
    • 今年強調されたのは、Javaの「透明性」。ベンダーだけでなく、コミュニティを重視し、仕様を決める過程をよりオープンにしていっている。
    • JavaEE7でのクラウド対応が延期されたことについて、クラウドはまだまだ標準化するには時期尚早との判断で、コミュニティや意見調査ではその英断が評価されているとのこと。
    • JavaEE7は2013年春にSDKが公開され、GlassFishへの実装はそれより後の予定。
    • JavaEE7に導入されるWebSocket対応については、Twitter4Jと組み合わせた寺田さん自作のデモが紹介され、画面上のいくつものブラウザにみんなのつぶやきがリアルタイムに反映されるアプリで盛り上がりました。WebSocketでの接続、メッセージパッシング、エラー、切断の各フェーズで呼ばれるメソッドを、対応するアノテーションをつけて定義するだけで実装できるのは、とても魅力的でした。また、サーバ側だけでなく、クライアント側のフレームワークも提供されるとのこと。
    • Avatarで言われているThin Server Architectureは、最初にViewのテンプレートを取ってきておいて、その後はそこに差し込むModelだけをJSON形式でWebSocketなどで通信する仕組み。毎回すべてのWebページのデータを通信しなくて良いので、通信量削減に大きく貢献するとのこと。
  • LT:github shopのグッズ、共同購入の告知（@ryosmsさん）
    • github shopのグッズを個人で買うと送料が高いから、みんなで買いませんか？というお誘いでした。エンジニア同士のつながりが強い岡山ならではな光景だなぁと思いました。
    • 個人的には会場でも人気だったパーカーか、このTシャツが良かったですが、手渡しのみ、とのことで残念ながら断念。。
  • プロジェクト・ラムダ・ライジング （角田裕樹さん @razon）
    • ランバダ改め、ラムダ。ランバダと呼ばれる由来は、JavaOne Tokyoのラムダのセッションで、会場に流れたお姉さんのアナウンスが、ランバダ〜と言ってしまったことによる、とのことでした。これは重要な情報w
    • ラムダは提唱されてから書き方が数多く議論され、1年前と比べると大きく変わっているとのこと。twitter経由で頂いた櫻庭さん（@skrb）からの情報でも、最近では主要な書き方はfixされてきたが、周辺のライブラリはどんどん変わっているとのことでした。
    • 実際にinterfaceを定義しラムダな書き方をやってみよう、というのをライブコーディングでされていたのですが、出来上がったコードをぱっと見るだけより、いろいろつまずきながらみんなで書いていくというのは理解も深まるし、勉強会に適したスタイルだなぁと感じました。人数次第ではあるけれども。
  • LT:Twitterで振り返る、JavaOne2012 San Francisco （@hiranasu）
    • 自身のスピーカーデビューでした。
    • JavaOneの時につぶやいた自身のツイートから印象的なものをピックアップして発表しました。
    • アウトプットは大事ですよ、アウトプットするにはそれ以上のインプットが必要ですよ、というまとめ方だったのですが、今思うとあんまりJavaOne関係ないなw
  • ひとりでもはじめるGitでバージョン管理 Ver1.1 （吉田貴文さん @zephiransas）
    • Java勉強会の枠を越えたw、粋な発表でした。
    • 基本的なことを一通り話した後、みんなgit使ってる？クライアント何使ってる？どんなことで困ってる？というインタラクティブな進行で、参加者側からも、Macのクライアントいっぱいあるんだけど何がおすすめか？といった質問や、日本語ファイル名やクロスプラットフォームの問題はみんなどう解決しているの？みたいな問題提起がされていて、とても良い雰囲気のセッションでした。MacのクライアントはGitHub for Macや、Source Treeを使っている人が多い印象でした。


懇親会では、岡山ならではのあるあるをたくさん聞かせて頂いて（車通勤だから、終電というセーフティーガードがない…とかw）、とても楽しかったです。また、いざ解散となって、建物出たところでまた話が盛り上がったりするなど、本当に岡山エンジニアは熱い！ぜひまた参加したいです、岡山。ありがとうございました！

JavaOne 2012 San Francisco 最終日

JavaOne5日目、ついに最終日を迎えました。


昨年はKeynoteが毎朝のように1時間半ずつあったのに対して、今年は初日の夕方にStrategy Keynote、Technical Keynoteを終えていたため、全体的なビジョンを押さえた上で個々のセッションに集中できるように配慮されていました。そして最終日は、前日のトレジャーアイランドでのイベントの翌日という事もあり、朝はちょっと遅めの9時から、Community Keynoteでスタートするという、参加者に優しい(?)スケジュールでした。以下、内容まとめです。

  • Community Keynote
    • 各国で活動するユーザグループに対して、感謝の意を伝え、今後も一緒に頑張りましょう、という会でした。ロンドンやブラジルのユーザーグループの活動を中心に紹介されていました。
    • Keynoteの中盤でサプライズ！Javaの父、James Goslingが登場しました！Goslingの行っている洋上からの環境測定プロジェクトが、Javaを使った面白いプロダクトに送られるDuke Choice Awardに選ばれたための講演とのことでしたが、会場は大盛り上がり！Sunのロゴが入ったTシャツを来てくる皮肉を効かせつつ(?)、最後は伝説のTシャツ投げまで行われました。”まさにこれがあのJavaOneかー！”と思った瞬間で感動しました。ぶれぶれな写真
  • [CON11546] Using the New javax.cache Caching Standard
    • JavaEE7に含まれる予定のJSR107(Java Cache Standard)についての講演でした。
    • 現在バージョン0.5が出来上がっており、来月には0.6を出す予定で、Java6があれば、JavaEEでなくても任意のコードに組み込む事が可能とのこと。
    • このキャッシュ機構が提供する機能としては、ConcurrentMapのようなAtomic性、イベントリスナー、統計取得、ジェネリクス、またオプションで、トランザクションやアノテーションベースでのキャッシュ機能があるとのこと。
    • JSR347（Data Grids for the Java Platform）との関係は、JSR347はJSR107に依存していて、その上にデータグリッド機能を追加している形になっているそうです。なお、JSR107はJavaEE7に入りますが、JSR347はまだ策定中です。
  • [CON7042] Building HTML5 Web Applications with Avatar
    • HTML5で提供されるWebSocketなどの技術を活用し、レスポンシブなサイトを構築するためのフレームワークである、Project Avatarの概要についてのセッションでした。今回のJavaOneでは、最も先進的かつ実験的な内容を扱うプロジェクトのひとつだと思われますが、それだけにその内容に、今回のJavaOneの中で一番面食らったセッションでした。。
    • Avatarは、JavaScriptをJVMの上で動かすというProject Nashornを活用して実装が進められており、クライアント側は、データバインディング、ナビゲーション、ローカルストレージなどのコントローラの機能が提供され、サーバ側では、ルーティング等の機能が提供されます。記述はXMLにJavaScriptが組み合わされ、JSFなどで使用するEL式も使われます。サーバ側コードの例 かねてからのJavaエンジニアにとっては、けっこう衝撃的な文法ではないでしょうか？！
    • ただ、これによってできるHTML5でできたWebサイトは、サーバとのやり取りは非同期通信、WebSocketなどを通じてサーバからのプッシュ配信も可能、Ajaxでのページ切り替えに対しても各々の状態にURLが振ってあってブラウザバックが可能、等々、いわゆるレスポンシブデザインが実現されていました。画面周りはHTML5でモダンな感じにでき、サーバの深い部分はJavaEEのアプリケーションコンテナや多数のAPIなどの資産を活かせるので、記述やデバッグが容易になるような工夫が十分にされれば、流行って行くのかもしれません。


全日程終了後は、日本人参加者での打ち上げということで、カニパーティーが催されました。写真 これは毎年恒例だとのことで、美味しいカニを食べながら、多くの初めての方とお話しさせて頂く事ができ、とても刺激になりました。（正確には、カニを食べだすと静かになっちゃうのですがw）とても良い思い出になりました。


今回のJavaOneでは、JavaOne自体にはサプライズは多くなかったものの、個人的には勉強になった部分が非常に多くあり、近々それもまとめたいと思います。


参加された皆様、とてもお世話になりました！本当にありがとうございました！

JavaOne 2012 San Francisco 4日目

JavaOne4日目は、昨夜のこともあり、再びテンション高めで臨みました。以下、まとめです。

  • [CON4006] Bean Validation 1.1: What’s New Under the Hood
    • JSR303で規定されている、アノテーションベースでBeanのプロパティのnullチェックや半角数字チェック等バリデーションを行うAPIである、Bean Validationについて聞きに行きました。マニアックw
    • メソッドの引数にもアノテーションをつけられるようになるとのこと。（Hibernate_Validatorでは既に実装されてるみたい？）こうすることで、メソッドの中はビジネスロジックに集中できます。なお、戻り値のnullチェックなどもできるようです（昔から？）。
    • 上記を含む、新しい1.1の仕様は10月末にドラフトが出て、JavaEE7に組み込まれて行くようです。
    • マニアックで人が少なかったためか、「DBの一意制約を満たしているか、バリデーションできないか？」「JPAと組み合わせれば、何かできるかもね！」みたいな、開発者とユーザのブレスト的なやり取りも行われ、もうすっかりJavaOneおなじみの光景となりました。こうやって仕様ができて行くんだなぁ、JavaOneはそういう声を生で集める重要な機会なんだなぁ、と改めて感じました。
  • [CON3566] JSR 353: Java API for JSON Processing
    • JavaOneTokyoの時に、@yusukeさんのお話を伺っていたので、その後の進展をぜひ聞いてみたかったのですが、部屋についた時には満員で、係の人に「full, full」と追い払われてしまいました。残念。。
    • 今回のJavaOneセッションは満席になることはあまりなく、予約をしていなくても割と聞きたいものを聞けたのですが、このJSONを始め、WebSocketなどのHTML5周り、SOAPやRESTなどのWeb技術のセッションは、長い長い入場列ができるのを何度も見かけているので、開発者の関心が高いことをうかがえます。
  • [CON3257] Script Bowl 2012: The Battle of the JVM-Based Languages
    • 同じくJavaOneTokyoで、最も思い出深かったJVM言語対決BoFの本場版があるというので、楽しみにしていました。
    • Scala、JRuby、Clojure、Groovyという顔ぶれだったのですが、Scalaはplay!を、JRubyはSinatraをアピールしていました。やはりWebを簡単に作れるというのは、大きな魅力のようです。GroovyはGrails…とは行かず、power assertやSpockなど、テストフレームワークの充実っぷりをアピールしていました。個人的にはそっちの方が惹かれます。。
    • 結果はScalaの優勝！Scalaはどんどん人口を増やしている感があるので、触ってみたいところです。
  • [CON4105] Java Batch for Cost-Optimized Business Efficiency
    • 入社以来バッチをたくさん書いていて、バッチフレームワークがついにJavaEE7で標準化されるというので、聞きに行きました。
    • 作りとしては、keynoteで多少見ていたので覚悟はしていたのですが、やはりSpring Batchをそのまま踏襲したような形になっていました。
    • セッションでは、参加者の間でも「バッチにコンテナは大げさだ」という意見と「バッチにコンテナを使えば、トランザクション管理などが簡単だ」という意見とでぶつかるシーンもあり、どのぐらい受け入れられて行くかは今後注目したいところです。
    • 肝心なバッチ管理ツールや、処理コストを考慮したバッチ起動などについては、時間切れのため説明されず＞＜ 残念。。
  • [CON6505] What’s New in Groovy 2.0?
    • GroovyのリーダーであるGuilliaume Laforgeによる、Groovyの既存機能と、新しく6月にリリースされたGroovy2.0の新機能についてのセッションを聞きに行きました。Guilliaume自身の記事がよくまとまっているので参考になります。和訳
    • 特に2.0の目玉である@TypeCheckedについては、その挙動について、丁寧に説明していました。また、静的コンパイルについても、Javaそのものとの実行速度と変わらないほど性能を向上させられるため、強調していました。写真
  • [CON10656] JavaEE.Next(): Java EE 7, 8, and Beyond
    • JavaEEのスペックリードが集まっての、Q&Aセッションでした。Q&Aセッションとは、特にスピーカーが資料を用意している訳でなく、参加者から聞きたい事を募ってその場で答えて行くという、ライブ感たっぷりな本場ならではのセッション形式で、これが初めての経験でした。
    • 英語がなかなか聞き取れず、、頑張ろうと思いましたorz


ところで、今日の夜は、同時開催中のOracle Open Worldの参加者も含めて、全員がAppreciation Eventという催しに招かれました。これは、サンフランシスコの沖合にあるトレジャーアイランドという島を丸ごと借り切って行われ、参加者は市内からバスでの送迎で島に向かいました。イベントは、Pearl Jamによるライブ、食べ放題・飲み放題、ゲームにヨット…まさにOracleに接待の様相でしたが、アメリカの（Oracleの？）スケールの大きさに圧倒されつつも、楽しんできました。いやぁ…すごかった。写真

明日はついに最終日！！

JavaOne 2012 San Francisco 3日目

JavaOneサンフランシスコ3日目は、早くもバテ気味で、興味のあったJava8に導入される新しい日付APIであるJSR-310（Project_ThreeTen？）のセッションなどがあったにも関わらず、朝イチはパスしてしまいました。（といっても、JSR-310のセッションがあったことには、夕方になってから気づいたのですが。セッションのタイトル名だけでは、内容がわかりづらいものもあるので要注意です;;） 昼から2つだけ出席したので、その内容をまとめます。

  • [CON3469] Design Patterns in Groovy
    • いわゆる、小人さんスクリプトや、やわらかな心臓といった7つの導入パターンについてではなく、JavaにはないGroovyらしい使い方について丁寧に説明していました。
    • 例えばイテレータに着眼すると、Groovyでもfor文は使えるけど、
collection.each {it}

を使えばGroovyらしくなるよ、for文のインデックス(int iとか)を使いたいなら

collection.eachWithIndex{e, i -> "index:$i value:$e"}

ってのがあるよ、長さが4のものだけループで回したいなら

collection.find {it.length() == 4}

ってできるよ、と、Javaユーザのハートを鷲掴む(?)セッションでした。

    • 他にも、metaClassへのメソッド追加（例えばjava.lang.Stringに好きなメソッドを追加できるような機能）や、methodMissing（存在しないメソッドを呼んだ時の挙動を定義できる機能）の例などを紹介していました。
    • 改めて、Groovyの強力さを実感し、ミッションクリティカルじゃないところは全部Groovyで書きたいな、と思わせる内容でした。
  • [CON3470] Scala Tricks
    • Scala書いた事ないのに、Groovyでテンション上がって、同じJVM言語だからという理由だけのノリで参加してしまいました。文法も知らず、関数型の概念もよくわかっていなかったので、当然の事ながら内容もさっぱりでした＞＜
    • ただ、Javaにはないタプルとトレイトという新しい概念があって、特にトレイトを使うと、あるクラスに何かの機能をちょこっと付け加えたい時にJavaだと継承などを使って新しいクラスを作る必要があるところが、もっと気軽にクラス拡張できるんだ、ということを、例を交えて解説してありました。（Scalaをちょっと知ってる人からすると、当たり前か…）
    • 今までScalaは難しいというイメージしかなかったので、そうじゃなく素敵な部分があるんだ、やってみたい、と思えたことが大きかったです。


なお、2つのセッションとも同じスピーカー（インド系？のおじさん）で、非常に早口だったのですが、言いたい事はきっちり言いつつ時間内にまとめ、さらに例え話が面白いために会場は笑いが絶えませんでした。ソースコードは事前に公開されていたのですが（JavaOne, San Francisco, September, 2012と書かれている2つ）、その完成系コードに至るまでの道のりをすべてライブコーディングで説明してくれて、一種のプレゼンの完成系を見た気がしました。今後、参考にしたいと思います。


ところで、今日はバテバテで、まったくセッションを聞きに行かなかったのですが、夜にお誘いがあってお茶していたら、11/9のJJUGでLTをさせてもらえることになりました！！まったりもしてられなくなりました！明日・明後日ラスト2日、走り切りたいと思います！

JavaOne 2012 San Francisco 2日目

昨日のKeynoteに続いて、いよいよ今日から各セッションが始まりました。

セッションは朝8時半から始まり、一番遅いもので夜9時半に終わります。まさに一日中Java漬け。本格的な初日でテンション高かったこともあり、朝イチから連続で取っていったのですが、夕方に力尽きてしまいました…。明日からはセーブして行かねば。。

以下に受講した内容を簡単にまとめます。（毎日断ることになると思いますが、英語が拙いので、間違ってるかもしれません＞＜ 間違ってたら教えて下さいm(_ _)m)

  • [CON7875] Building Portable Java EE 6 Applications in Eclipse
    • JavaEE6のデモというと、NetBeansでテンプレートをバリバリ使うものが多いですが、Eclipseでも同じようにできるよ！というセッションでした。確かにダイアログで選んで行くだけでJSF+JPAのJavaEEアプリケーションができていました。
    • ライブコーディングのようなデモだったのですが、途中でアプリが500エラーばかり返すようになり、会場全体で協力してデバッグしていました。確かにJavaEE6になり記述量は格段に減り、見通しも良くなっているのですが、慣れない人がエラーの内容だけでどこが悪いのかを判断するのはハードルが高い気がします。特にEclipseだと、Eclipseのエラーとして上がってきたり、ホットデプロイが悪さしていてサーバ再起動でなおってしまったり。。何が起きてるのかがわかりやすくなると敷居がより下がるのではないでしょうか。
    • セッション後はホールで軽食（朝ご飯？）が振る舞われていました。写真
  • [CON3255] JSR 331: Constraint Programming API
    • Constraint Programming（制約プログラミング）とは、制約を定式化し、それを満たすような解を探して見つけ出す手法のことで、スケジューリングやリソースの割当問題などがこれに当たります。（大学時代の研究テーマだったため、中途半端に間違った事を書くと怒られそうなので、難しい言い方してます;;）
    • 要は、現実世界にある組合せ最適化問題を式にして、ソルバーと呼ばれるプログラムに食わせて答えを探すのですが、これがソルバーごとにAPIが異なるので、インタフェースを統一して標準化しましょう、というのがJSR-331だということらしいです。
    • 大学時代、ILOG(今はIBM)のCPLEXというソルバーに式を食わせようと頑張ってプログラムした辛い記憶があるので、インタフェースが統一されて、コードはそのままにソルバーを色々変えて試してみる、とかできるとなると、とても素敵だと思います。ただ、こんなニッチなAPI、そんなにいっぱい使う人がいるんでしょうか。。
  • [CON4701] 50 Tips in 50 Minutes for GlassFish Fans
    • GlassFishのWikiで公開されてる内容を50分で紹介してしまおう、という無茶な企画。2人組で5個ずつ紹介していったのですが、丁寧に説明するJavaEEのエバンジェリストArun Guptaに対して、相方のスピーカーは「1個60秒以上かかってるよ！」と怒ってましたw
    • セッションのやり方はともかく、上記のWikiでは、クラスタの設定方法あれこれ(15,17など)や、JMXでサーバ情報を取得するあれこれ(23-25)、RESTでサーバを操作するあれこれ(31-34)など、有益なTipsが多く載っていたので、一見の価値ありです。
  • [CON4212] Java Persistence 2.1: What’s New
    • JavaEE7でマイナーバージョンアップされるJPA2.1について、JavaEEのスペックリードであるLinda Demichielが説明をしてくれました。
    • 2.1では、以下の3つの大きな機能追加と、DBのFunctionを呼び出せるようになる等の小さな機能追加がされるようです。
      • スキーマ自動生成：テーブル作成だけでなく、@Indexや@ForeignKeyなどのアノテーションが追加され、スキーマを構成するDDLをEntityクラスだけでより表現できるようになります。足りないDDLは、スクリプトファイルをプロパティで指定できるので、そこに記述しておけば実行してくれるようです。
      • 非同期PersistenceContext：今までは基本的にすべてのクエリがJTA等のトランザクション内で扱われていましたが、EntityManagerを宣言するアノテーションにsynchronization=UNSYNCHRONIZEDのように記述すると、トランザクション管理せずパフォーマンス向上を図れるようになるようです。非同期として宣言したPersistenceContextでコミットorロールバックしたい場合は、em.joinTransaction()を呼ぶと、通常時と同じようにトランザクション管理されます。
      • AttributeConversion：DBで値を持つ時の型や単位（キロ・ポンド等）と、Entityで持つ時の型や単位を変えたいとき、AttributeConverterというインタフェースを実装したMyConverterクラスを作っておいて、Entity内の持ち方を変えたいプロパティに@Convert(MyConverter.class)をつけておくと、DBに書くときや読み出すときに自動で値を変換してくれるようになります。
    • JPAはJavaEEのORマッパー決定版という感じなので、引き続き一般性と柔軟性のバランスを取りながら拡張されていくのが楽しみです。
  • [CON4038] Project EASEL: Developing and Managing HTML5 in a Java World
    • Keynoteで小さいながらもサプライズっぽくなった、NetBeansからchromeの表示を操るアレの詳細な説明でした。正直、ここの辺りからバテてしまい、詳細まで追えませんでした＞＜
    • 強調されていたのは、Project Easelは、WYSIWYGエディターではなく、JavaFXやJSFなどのJavaSolutionのひとつでもなく、Photoshopのようなデザインツールでもない、webkitと同期するコード補完機能に過ぎない、ということでした。
  • [BOF7664] JPA 2.1 Tips, Tricks, and Examples
    • BOFということで、軽いノリでついてきてね、という前置きから始まり、猛烈な速さの英語で参加者とのやり取りをしながらセッションが進みました。「2.1の新機能の非同期PersistenceContext、どうよ？」とか「スキーマ自動生成は、ぶっちゃけそんなにいらないよね！」みたいな感じで、参加者が腹を抱えて大爆笑するシーンもありました。印象的だったのは、スピーカーが実際の開発担当で、最後に「Now, Your turn! 2.2に盛り込みたい機能ある？」で締めくくったこと。日本でのJavaOneでもBOFはあったものの、こんなに直接的に仕様に意見できる機会があるなんて、本場ならではだなぁ、と感じました。


夜は、昨日同様ライブに出向き、Jimmy Cliffの歌声に元気をもらってきました。写真 今年で64歳らしいのですが、動きもテンションも声量も歌声も、つやつやの20代みたいでした。すごい！

明日も引き続き楽しみたいと思います。


余談ですが、昨日のKeynote開始時に流れたオープニングムービーがアップされていました。youtube 昨年のJavaラップは「もっとコードを書け」的なブラック企業っぽいものでしたがw、今年はなんとなく幸せな気分になれる動画でした。ぜひぜひ。