JavaOne 2017 レポート 10/3 Day-3 技術セッション+謎のキーノート
さて、もう10日は経っていますが、粛々と3日目のレポートです。
Refactoring Design Patterns the Functional Way (in Scala)
ちょっと最初の15分ほど遅刻してしまいました。 GoFのデザインパターンをいくつかピックアップして、関数型言語として良い書き方にリファクタリングしよう!という話です。
- 良い書き方とは?
- 以下の4つを満たす書き方
- No Side-effects
- No Mutation
- No mutable SZtate
- Declarativity
- 以下の4つを満たす書き方
- GoFのデザインパターンをリファクタリングしよう
Immutable Collections
「不変コレクション」についてのディープ目のセッション。
まずは、Java標準APIやcommons系ライブラリ、Scala、Closureなどでの不変コレクションの現状を整理。 そのあとは、Hash Array Mapped Tries(HAMTs)というトライ木を使ったアルゴリズムで効率の良い不変コレクションを実装してみたよ、みたいな話でした。
Githubのリポジトリは多分これ: https://github.com/PaulSandoz/per
Modules in One Lesson
JavaのプロジェクトリードであるMark Reinhold氏のライブコーディングセッション。
以下、ライブコーディングを見ながらとったメモ。
- jlinkコマンドで必要最小限のJVMが作れる
--output
オプションで、bin配下に好きな名前のアプリ起動コマンドも作れる
- 実行時例外
- 依存先モジュールがモジュールパス上に見つからないと、
FindException
がスローされる - 依存先モジュールで、使おうとしているメソッドが
exports
されていない場合は、IllegalAccessException
がスローされる
- 依存先モジュールがモジュールパス上に見つからないと、
Building from Minutes to Seconds: Maximizing Incrementality with Gradle
Groovyコミッタであり、@CompileStatic
を始め数々の性能向上を実現してきた、現在はGradle, Inc.にお勤めのCedric氏のGradleセッション。
Gradleにおけるビルド時間短縮のための4つの機能について説明。
- なぜビルド時間を短縮するのか
- 1分でもビルドが早くなると、人件費とかコストに直結する
- Incremental Builds (無駄なタスク実行を避ける)
- ソースコードが変更されてない場合はcompileタスクやtestタスクを実行する必要はない
- input/outputを明示すると、それらで変更有無を電波できるので最小限のビルドができる
- タスクごとにinputs/outputsを宣言しておく
- 自前でタスククラスを実装する場合は、
execute
メソッドの実装でinputsをチェックしてタスクの実行/スキップを分岐する必要がある
- Compile Avoidance (無駄なコンパイルを避ける?)
- コンパイル時の依存関係が漏れ出す問題
- (例)あるライブラリで実装詳細としてguavaを使っている場合、
compile
コンフィギューレーションにguavaを依存関係として定義して使うと...- 下流(=利用する側)の
compile
コンフィギュレーションに、推移的にguavaが漏れ出してくる - ライブラリの実装詳細として依存関係の変更で、下流の依存関係が破壊されるリスクがある
- 下流(=利用する側)の
- Gradle 3.4から
api
/implementation
という分け方を導入したapi
コンフィギュレーション: 下流で依存する必要がある(直接使用するインタフェース等の)依存関係implementation
コンフィギュレーション: 下流で依存する必要がない(直接使用しないクラス等の)依存関係
- (例)あるライブラリで実装詳細としてguavaを使っている場合、
- 依存関係においてコンパイル/ランタイムのクラスパスは異なるセマンティクスを持つ
- コンパイル時の依存関係が漏れ出す問題
- Incremental Compilation (変更があったファイルとそれに関連する部分だけをコンパイルする)
- どうやるかはコンパイル対象の言語依存
- Gradleは、JavaのIncremental Compilationはサポートしてる(デフォルトOFF)
- デフォルトでONにするのはGradle 5.xぐらいになりそう
- Q: サードパーティライブラリの定数を使っているクラスがあったとして、定数の値が変わっていたら、利用側のコンパイルも必要だと思う?
- A: 必要。実はクラスファイルには値自体が展開されて保持されている。
- JLSでは「コンスタントプールに入れる必要はない」と書いてあるけど、実際現状では展開されている
- このため、Gradleでは、全てのクラスのバイトコードを解析して変更必要性を検知している(力技)
- (以降、時間切れで割愛)
- A: 必要。実はクラスファイルには値自体が展開されて保持されている。
- Annotation Processor
- Variant-aware dependency management
Migrating to Modules
再びMark Reinholdのライブコーディング。
以下、ライブコーディングを見ながらとったメモ。
- Automatic Modules
- モジュール対応していないサードパーティライブラリのJARファイルなどは「Automatic Modules」として扱われる
- JARファイルの名前規約でモジュール名が決まる
- foo-bar.jar →
foo.bar
モジュール
- foo-bar.jar →
- 依存関係上に登場する全てのモジュールを
requires
しているものとして扱う
- JARファイルの名前規約でモジュール名が決まる
- モジュール対応していないサードパーティライブラリのJARファイルなどは「Automatic Modules」として扱われる
- エンティティやDTOなど、データバインディングフレームワークなどに使われるクラスは自モジュール外であるフレームワークから使えるように
exports
する必要がある - 実行時にjavaコマンドに
--show-module-resolution
オプションをつけると、モジュールの解決結果が標準出力に出力される - jdepsが便利
-s/-summary
オプションをつけて実行すると、そのモジュールが必要としている他のモジュールが出力される- モジュール非対応のJARファイルに
jdeps --generate-module-info <出力するmodule-info.javaファイルのパス> <JARファイルのパス>
を実行すると、指定したファイル名でmodule-info.javaの雛形が生成される
- インタフェースに対する実装クラスはimplパッケージなどにひとまとめにしておくと、モジュール外から隠蔽しやすい
requires transitive
requires m1;
という依存関係を持つモジュールm2を、モジュールm3からrequires transitive m2;
と推移的に依存しておくと、モジュールm3でrequires m2;
としたときに、m3はm1とm2に依存していることになる- m1で提供するインタフェースをm2で実装しているようなときに、m2だけ指定すれば良いので楽 (Mavenとかの推移的依存関係みたいな感じ)
JUnit 5: New Opportunities for Testing on the JVM
JUnit 5の概要説明のセッション。
- 挙手コーナ
- JUnit 5はクラウドファンディングで資金を募って一から再設計&実装された
- (サムライズムのロゴが映ってました)
- (なお、自分も個人でエントリしてます。後日DLして確認したらスライドも拡大すればなんとか読める程度に映ってました。 http://junit.org/junit4/junit-lambda-contributors.html)
JUnit 5 = Platform + Jupiter + Vintage
Eclipseを使ったデモ
- Ruleはpublicフィールドに
- Tagを使ってテストメソッドを好きに分類して、タグの種類ごとに選択式に実行できる
- テストメソッドの引数に
TestInfo
を受け取れる。テスト名とかタグ名とかを動的に取り出せる @TestName
でテスト名がわりに任意の文章を記述できる- レポートではテストメソッドの代わりにこの文章が表示される
- 日本語テストメソッド名の制約を気にしなくてよくなった(句読点、先頭数字、とか)
- 絵文字も対応(なぜか超盛り上がる)
- レポートではテストメソッドの代わりにこの文章が表示される
- テストクラスがネストでかける
- フィクスチャごとにグルーピングすると便利
- 結果レポートでもネスト構造でドリルダウン表示できる
- Jupiterが提供するパラメタライズドテストの記法は、Spock使いとしてはやはりうーんという感想
Developer Keynote
「Live for the Code」という題目での位置付けのよくわからないキーノート。
Oracleクラウドを使うとこんなに簡単にサービスできますよー的な感じだったっぽい。 いわゆるスポンサー枠というか宣伝メインっぽい枠でした。 みんな大好きSlackの人が壇上に登場してました。
Automated Functional Web Testing on the JVM with Geb
CERN(欧州原子核研究機構)の人による、ブラウザを使ったテストが簡単にかけるGeb(じぇぶ)の入門的な紹介セッション。 内容的には全部知っていますが、応援の気持ちで聴講してきました。
Gebについて気になる人は、ちょうど同じ頃に公開されたこちらの記事などがおすすめです。
本日のディナー
話題沸騰(?)のメキシカンファストフード「チポトレ」のブリトーボウル(丼)にチャレンジしてみました。
なお、実食した結果↓
なるほどうまい
— Yasuharu Nakano (@nobeans) 2017年10月4日
飽きた
— Yasuharu Nakano (@nobeans) 2017年10月4日
その後、Westfield(Powell Station前のショッピングモール)の4Fにあるスポーツバー的なところで、ビールと軽食をいただきました。