Java Day Tokyo 2014に参加してきました #javadaytokyo

概要

2014年5月22日に開催されたJava Day Tokyo 2014に参加してきました。

• お客様の声 | 地鎮祭お届け隊
• セッション資料
  • 一部資料も公開されています。

去年は仕事のため参加できませんでしたが今年は仕事あるのに！有給使わないで！参加許可が出ました。
ただ、私用により昼前からの参加になってしまいましたが。。。（基調講演残り30分のとこで参加）

参考URL

• Java Day Tokyo 2014 #javadaytokyo - Togetter
• Oracle Blogs 日本語のまとめ: [Java, JavaScript] Java Day Tokyo 2014
• #JavaDayTokyo 2014に参加して熱気を感じてきました！ - Challenge Java EE !
• #JavaDayTokyo 2014に参加してきました！ - きつねとJava！
• http://my-coding-memo.ldblog.jp/archives/7245868.html

自分が学んだことまとめ

自分が新たに学んだことは↓な感じ。

• Java8は早い。何もせずにJava8にするだけでパフォーマンスアップする。（2/3位とか）
• 新JavascriptエンジンNashornが結構楽しそう。
  • 7までのエンジンRhinoより2〜8倍早くなったとか言ってた気がする。
• リファクタリングという別タスクになってしまうと、許可が必要で、許可はおりない。
• テスト駆動開発入門復刊予定！
• ラムダで使えるメソッド？はかなり充実してるっぽい。

特にNashornは楽しそう。
業務で使えるかどうかは置いといてとりあえずいじってみる予定。

後、Raspberry Pi購入したので、JavaとGroovy入れる！

以下メモ。

基調講演

私用によりラスト30分位から参加。

• Dukeチェスロボット
• ユーザグループの話
• Javaが他のプログラミングとは違う。
• エコシステムが違う
• イノベーション
• コミュニティ
• 日本Javaユーザグループ
• JJUGCCC
  • 367名参加
  • 年2回
  • 月1第4週の水曜日19〜
• ユーザグループ
  • 他の人の経験から学ぶ事ができる。

JavaScript Running On JavaVM: Nashorn

D-1 13:30-14:20
JavaScript Running On JavaVM: Nashorn (新JavaScriptエンジン)

Java SE 8では、これまで同梱していたRhinoに代わり、Nashornという新しい JavaScriptエンジンが導入されました。このセッションでは、Nashornの生まれた経緯、特徴、将来に追加予定の機能などをご紹介します。また、このNashornを用いたサーバー・サイドJavaScriptフ レームワークであるAvatarやAvatar.jsについても簡単に紹介します。

#jdk2014_D1

• Oracle Blogs 日本語のまとめ: 江草家について
  • の中の人 @OraBlogs_jp
• Nashorn
  • サーバサイドのJavascriptについて。
• JavaVMの上で動く
• CompactProfiles 1でも動く
• Rhinoの置き換え
  • らいの
  • 2〜4倍位のパフォーマンス
• セキュリティ、パフォーマンス
• 作りなおすよりかは1から作りなおすほうがいいんじゃね。
• Javascriptで書けるものはJavascriptで書くよね。
  • 何とかの法則
• JavaとJavascript間での相互呼び出し
  • 新しいコマンドラインツールの導入（jjs）
• $JAVA_HOME/bin/jjs
  • JRE配下にもあるよ
• サポートしていないのは。。。
  • ECMAScript6
  • DOM/CSS及びDOM/CSS関連ライブラリ
  • ブラウザAPIやブラウザエミュレータ
• Java typrの参照を取得
• Javaオブジェクトのプロパティアクセス
• Lamda SAM Script関数の関係
• スコープ及びコンテキスト
• javascriptからJavaを呼ぶ時には

var ArrayList = Java.type('java.util.ArrayList')
var list = new ArrayList()
list.add("a")

• Server Side javascript
• Avatara.js
  • Node.jsで利用できるモジュールをほぼそのまま利用可能
  • フレームワーク？でいいのかな。
  • Avater.js = Node + Java
  • Avatar is not dead!

• まとめ
  • Javaと緊密に統合
  • バイトコードになる
  • 今後性能向上、機能追加、新しい仕様に対応

• サーバーサイド
  • Avater.js、Avatarは鋭意開発中
  • 性能は今の所よくないという話だが、改善していく。
  • OPENJDK なので、みんな協力してね！

Java SE 8におけるHotSpotの進化

C-2 14:35-15:25
Java SE 8におけるHotSpotの進化
概要
Java SE 8の主要な機能としてLambda式、Date & Time APIなどが取り上げられることが多いですが、Java SE 8ではJavaVMに対しても様々な改良が施されています。本セッションでは、HotSpot VMにおける改良点などを分かりやすく紹介します。

• バッグデイビッド
  • 元JRockitのエンジニア

• PermGenの廃止
• Tiered Compilation
  • 色々変わったことはあるけど↑2つだけに絞って話す。

• PermGen廃止
  • Perm Genとは
  • クラスのメタデータなどを格納する場所
  • バイトコード
  • internされた文字列
  • staticフィールドの値
• 悪いところ
  • サイジングが困難
    • ロードするクラスの数
    • ロードするクラスの大きさ
    • クラスのオーバーヘッド
  • デフォルトが小さい（64mb-85mb））
  • パフォーマンスへの悪影響
• いいところ
  • あったけ？ｗ

• metadataは自由に拡張が可能。
  • サイズの制限がない
  • 自由にサイズ変更が可能なので、ユーザが意識する必要性がない
• GCシステムが管理する必要がない
  • GCのパフォーマンスがよくなる
• アンロードをクラスローダの単位で行う

• High Water Mark（高水位標）
  • Full GCが発生しないとMetaSpaceのコレクションが行われない
  • FullGCの頻度が低いシステムのメモリ使用量を制限する必要がある。
  • MetaSpaceのサイズがHWMを超えるとFULLGCが実行される
• 調整する必要がある場合
  • FULL GCの頻度が高過ぎる時
  • メモリの使用量が大きすぎる時

• Compressed Oops（圧縮参照）
  • 64bitマシンでも、オブジェクトのアドレスを32bitに格納する
  • javaヒープの使用量を節約
  • ヒープのベースアドレスからのオフセットを利用
  • さらにアドレスのLSBを省略

• --XX:MaxMetaspaceSize
  • デフォルト=unlimited
  • MetaSpaceの最大サイズ（バイト数）を設定する
  • 実行時
• --XX:MetaSpaceSize
  • デフォルト=21MB
  • 起動時にFullGCの頻度を減らすために大きくする
  • 起動時（初期値ってことかな。）
• --XX:MinMetaspaceFreeRatio
  • デフォルト=40
• --XX:MaxMetaspaceFreeRatio
  • デフォルト=70
  • 単位はパーセント
• --XX:+UseCompressedClassPointers
  • 64bitではデフォルトで有効
• --XX:CompressedClassSpaceSize
  • デフォルト=1G
  • 変更ができないため、デフォルト値が大きい
  • 起動時にはメモリをreserveするだけ
  • 必要に応じてcommitしていく

• ツールも対応
  • jmap jstat jcmd なども対応

• Tiered Compilations（「階層型コンパイル」）
  • JDK8の新機能ではない
  • 古い実装はHotSpotExpressで6u25までバックポートされました。
  • JDK8ではようやくデフォルトで有効
  • JDK8の新しい実装は従来のバージョンよりかなり充実

• jitコンパイラ

• C1（-client）
  • コンパイル処理が早い
  • 生成されるコードが比較的速くない
• C2（-server）
  • コンパイル処理に時間が掛かる
  • 生成されるコードが速い

• 起動を早くしたい場合 C1
• 起動後のパフォーマンスが必要な場合 C2
• ↑の選ぶ必要を無くす
• JMXで診断コマンドを実行

• まとめ
  • 結果として、7→8にすることによってパフォーマンスは2/3位の速さになっているっぽい。
  • とりあえず8使っとけ。努力しなくてこんなに早くなるよ！

Javaアプリケーション開発におけるテストとTDDの実践

C-3 15:40-16:30
Javaアプリケーション開発におけるテストとTDDの実践
概要
JUnitを使ったユニット・テストの自動化はこの10年で広まり、多くの現場に導入されるまでにいたりました。当セッションでは、さらに先に進んだトピックである、DBをからめたテスト、Web UIを含めたテスト、統合テストの自動化、テスト駆動開発、CIツール、テスト・カバレッジの話など、Javaアプリケーション開発現場におけるテストとTDDの実践について知見を共有します。

• JUnitは95%位使っている。
  • その後！についてリレートークで話していく。
• JUnitテストしてるけど効果的なテストができているかは別。
  • 手作業したら負け！
• 自動化のメリット
  • 手作業によるコストの削減・ミスの削減
  • コンピュータリソースを有効活用
  • 文句を言わずに繰り返し何度でも実行
  • 楽しい
• ユニットテストは最高のパートナー

• 変更毎にテストを実行
  • ソースコードの修正の影響
  • 可能な限り早く影響を検知
  • リグレッション（デグレーション）対策
    • ×防止する
    • ○即座に修正できるようにする

• DBとかのテスト
  • モックで実行する派
  • 実際に繋げる派
• 初期化-Setup
  • DBデータの初期化
    • 関連テーブルの削除
    • シーケンス
    • システム時間
    • 初期化にかかる処理時間
  • テスト用データの準備
• 準備 Exercise
  • テスト対象オブジェクトの準備
  • 1つのメソッド（SQL）毎にテストを実行
• 検証 Verify
  • モデルの検証
  • DBデータへの反映の検証
• 後処理
  • 1つのテストで複数のことを検証しない
  • 次のテストの初期化に任せて何もしない

• テスト方針
  • リアルDBを利用
  • フィクスチャはYAMLフォーマットで定義
  • 初期化処理でDBをセットアップ
  • 後処理ではDBを初期化しない

• DBUnit
  • ↑で言ってたことをやってくれるフレームワーク
  • About DbUnit

• その他のポイント
  • フィクスチャ重要
  • ローカル実行
  • スローテスト
  • とかとか

• 統合テストを自動化せよ
  • 統合テストへの道
  • DBとかAPPサーバとかUIを含む再実行可能な統合テストは？

• 手動統合テスト
  • 膨大なExcelテスト仕様書
  • 膨大なテスト実行コスト
  • 即レガシー、触るな危険
• 自動化された統合テスト
  • 手動テストの最小化
  • コスト削減
  • レガシー脱却
  • 楽しい

• Arquillian
  • Arquillian · Write Real Tests
  • モックするな！
  • ホンモノに近いテストを使用
  • 本物の実行環境へデプロイ、本物の実行環境上でテスト
  • 公式？日本語でもOK。
  • blogとかもあがってきている。
  • Seleniumなども含まれて、インジェクションされてるらしい。
  • Mock is dead. Long live testing.
  • 何でもかんでもモックにするのはよくないよ！
    • 勿論必要な場合はあるけどね！

• TDDの話
  • みんな知っているけど、やっていない。
• TDDのサイクル
  • RED GREEN REFACTOR
  • リファクタリングという別タスクになってしまうと、許可が必要で、許可はおりない。
  • 開発工数は増えるが、デバッグの工数が減るので、全体的な工数が減る。
• テストは品質をあげない。
  • テストを使用していくことで品質はあがる。
• カバレッジ。
  • 書かれているコードに対してテストが行われている事を確認しているだけ。
  • バグは書かれていないコードで発生する（仕様漏れだとか。）
• こだわるなかれ。
  • TDDにこだわるな
  • テストファーストにこだわるな
  • ユニットテストにこだわるな
• こだわるとすれば↓
  • 再現性が有る
  • 繰り返し可能
  • 互いに独立

• テスト駆動開発入門復刊予定！ #jdt2014_C3 #javadaytokyo

Lambda式とストリームAPI、並列処理の詳細

A-4 16:45-17:35
Lambda式とストリームAPI、並列処理の詳細
概要
Java SE 8におけるクラス・ライブラリ拡張の目玉は、Stream APIです。この新しい APIはLambda式を中心に設計されており、並列プログラミングが簡単に実装できるようになるだけではなく、よりスマートなコーディング・スタイルを提供します。

本セッションは、Stream APIを利用したフィルタ、マップといった基本的な操作から、より難しいリダクション、グルーピング、コレクションといった操作まで紹介します。また、並列処理についても詳しく紹介します。通常、並列処理を有効にするために、"parallel()"メソッドを追加することで実現できます。しかし単に"parallel()"メソッドを追加する方法には問題があります。たとえば並列処理を行った結果、間違えた結果を返す場合や、想定したパフォーマンスが得られない等のいくつかの落とし穴があります。実際にいくつかの落とし穴のコードを示しながら、その問題をどのようにして解決するかについても説明します。

このセッションは英語だったこと、A-2？からの連続セッションだったことからあまり理解できなかった。。。
ただ、内容はわからなかったもののコードが多かったので実際のラムダの使用方法を見ながら概要はわかった感じ。

• @FunctionalInterfase
  • このアノテーションがあると、ラムダ式を使えるよと。
• 英語はイマイチだったけど、コードを追うことで旧コードからラムダ及びストリームを使用したコードへの変化はわかりやすい。
• ラムダの中ではローカル変数は変えられない。
• オブジェクトの中身ならば変えれるが、並列処理した場合に困る。
• common Collectors
  • というのがラムダの中で使えるらしい。
• StreamsAPIはラムダの仕様を中心に考えられています。
  • StreamAPIによってアプリケーションの作り方が変わっていきます、

おまけ