JavaOne 2017 レポート 10/4 Day-4 Moscone会場最終日

翌日の最終日(Day-5)はMariottホテルの会議室がセッション会場となるので、Moscone Westに通うのはこの日が最後です。そろそろ終わりもみえてきて、並行して会場撤収なども始まるので、この辺りからだんだん寂しい雰囲気が漂い始めます。

f:id:nobeans:20171004183037j:plain:w300

Polyglot Adventures for the Modern Java Developers

モダンなJava開発プロジェクトを進めるために色々な言語を適材適所で使おう、という言語/ツールの紹介セッション。

どの言語がベストというのはない。それぞれが特定の領域で強みを持っている、というだけ
- だから、適材適所で臆せずに混ぜ込んで使おう
Setup-as-code
- シェルスクリプトよりも、Gradleタスク/Groovyが便利
Build-as-code
- Mavenは良い。ただし、Gradleは100倍速い(?)
  - Gradleはとても柔軟で、なんでもビルドできる
  - 色々な言語を混ぜ込んだプロジェクトでもビルドが簡単
Main-as-code
- メイン言語としてはJavaで間違いない
- ただし、Kotlinもメイン言語として考慮に値する (まさかのKotlin推し)
  - ScalaとかClojureとかじゃなくて、なぜKotlin？
    - Java開発者が学びやすい
    - バランスが良い
    - null安全性、シンタックスシュガー、etc.
    - JDK 6互換性
    - ライブラリサイズが小さい
    - IDE/ツールサポートが良い
Frontend-as-code
- JavaScript一択
  - TypeScript or (ECMAScript2015 + Babel)
  - node + npm + webbpack
Test-as-code
- unit/integrationテストには、Groovy/Spock
  - パラメタライズドテストが強力で読みやすい
- 負荷テストには、Scala/Gatling
  - CLIで実行して、クールなHTMLレポートが出力できる
Pipeline-as-code
- Jenkins 2からJenkinsfileにGroovy DSLでかけるようになった便利になった
Infrastructure-as-code
- Docker!!!!!!
- ローカルVMをセットアップするなら、Vagrant/Ruby
- プロビジョニングには、Python/Ansible
- クラスタのオーケストレーションには、Kubernetes
Documentation-as-code
- Asciidoc + AsciidoctorJ + Gradle
Architecture-as-code
- Structurizr
  - アーキテクチャの構造イメージをDSLで記述できる
- QAvalidator
  - バリデーションできる(?)
Presentation-as-code
- Markdown
  - 「今回のスライドもMarkdownで書きました」
「色々な言語やツールを使おうとすると学習コストがーという人がいるけど、実際やってみたら確かにそういう面もあるけど、トータルでハッピーでしたよ」

How Languages Influence Each Other: Reflections on 14 Years of Apache Groovy

f:id:nobeans:20171004104215j:plain:w300

我らがGroovyのProject Lead(Apache配下になってからは正確にはPMC Chair)であるGuillaume Laforge氏による、Groovyが誕生してから14年間における、他の言語との影響の相互作用について紹介するセッション。なお、あくまでセッションメモなのでそれは事実と違う！などクレームはご遠慮ください。

Groovy
- 2003年生まれで、今年で14歳
- Apacheに移ってからDL数はかなり増えてる
- シンタックス的にC言語の系列
- "ほぼJava"
Groovyが他の言語から受けた影響
- Smalltalkから
  - (初期の)クロージャの引数宣言部の区切り
    - 最初Smalltalkと同じくパイプ記号だったが、{ a = 1 | 2 | a * 23 }と書いた時に、1 | 2と2 | a * 23のどっちがビット演算子でどっちが引数宣言部区切りなのか区別できないので、現在の->に変えた。
  - 名前付きパラメータ
  - メソッド呼び出しのカッコを省略できる
  - コレクション操作のメソッド名 collect / inject
- Pythonから
  - リストやマップの[], [a: 1]というリテラル記法
Groovyから他の言語に与えた影響
- Trailing Closure to Swift, Kotlin
  - 最後のクロージャ引数がカッコの外に出してかけるやつ
  - Groovyでは特に名前がなかったけど、Swiftで「Trailing Closures」という名前がついたので今後そう呼ぶことにする(!?)
- Range to Swift
  - Range自体は元々Rubyにあったけど、1..3(=1,2,3)、1...3(=1,2)の後者の記法を、Groovyでは1..<3と直感的にわかりやすくした。この記法がSwiftへ
- Spaceship演算子(<=>) to PHP, Ceylon, Ruby
- 色々 to Kotlin
  - クロージャ文法
  - クロージャの暗黙変数it
  - Builderのコンセプト
    - クロージャでDSLを書いてメソッドミッシングをトリガとして情報を構築するやつ
  - AST変換 (@Immutable, @Delegate, @Lazy)
  - メソッドを使った演算子オーバロード
    - +はplus()のシンタックシュガーであり、plus()をオーバロードして挙動を変えられる、というやつ
  - セミコロンが省略できる
  - nullセーフ演算子(?.)
  - エルビス演算子(?:)
    - gccでは3項演算子の第2項が省略できる、というのが元祖だけど、演算子化して「エルビス」って言い出したのはGroovyが最初
  - asを使った別名インポート
言語同士はインスパイアしあう関係にある
- パーフェクトな言語はない
- でもみんな改善し続けてるよ
Q&A
- Q: Groovyのswitchは、Java 7でやっと対応したString以外にもなんでもマッチングできて便利だけど、あれが各言語でのパターンマッチングに影響を与えたのかな？
  - A: わかりません。ちなみに、Groovyでもここ10年くらいパターンマッチング実現しようと頑張ってるけど、全然完成してないです。
- Q: GroovyのJava 8シンタックスへの追随はいつになる？
  - A: ちょうど新しいパーサ(Parrot)を入れた2.6-alphaを出したところだけど、これが正式リリースされたら、Java 8のラムダ記法もクロージャとしてパースできるようになる予定。
- Q: Project Amberとかで、6ヶ月ごとに新しいシンタックス出てきたら追随大変じゃない？
  - A: わかりません。まあ、新しいシンタックスへの対応はすぐには難しいかもだけど、動かすこと自体はできるんじゃないかと(よく聞き取れず)
- Q: データサイエンス分野ではPythonが大人気だけど、なんでGroovyはその分野で使われないの？
  - A: (よく聞き取れず)
- Q: Jigsaw対応はどうなってるの？
  - A: これはかなりの難題です。Jigsaw対応第一弾は2.6としてリリース予定ですが、一応動くけど警告が出る、という段階です。完全な対応にはGroovy自体のモジュール構成を破壊的に変更しないといけません。なので、メジャーアップデートとなる3.0での完全対応を目指すことになるでしょう。その辺も含めて今まさに検討＆対応中です。

Graal VM: High-Performance Polyglot Runtime

Graal(グラール)というHotspotの代替的な(?)実行環境の説明セッション。 JavaOneで初めてGraalという単語自体を認識した程度の情弱なのですが、なんだか一部の日本人参加者的に要注目らしいので、急遽聴講してみました。そのうちJJUGとかで他の参加者の人から詳しい日本語情報が出てくるようなので正座してお待ちしております。

Graal＝Polyglotからinteroperableな実行環境
Streamを使ったベンチマーク例
- mapを1つ使ったコード
  - Hotspot: 40ns
  - Graal: 11ns
- mapをさらに2つ追加すると
  - Hotspot: 200ns
  - Graal: 11ns (!!!!!)
npm, ruby, node, scalaとかもサポート
ineroperableなので、JavaScriptからJavaやRなども呼べる
- Rを呼ぶ場合、初回は裏でRプロセスを起動するので遅いけど、2回目以降は速くなる
JavaScriptの場合、Chromeの開発者ツールでDebugできる
- (仕組みよくわからず)
Visulal VMが同梱されてる
SubstrateVM
- Javaをプリコンパイルして動かせる
- Hotspotではなく、svmというVM上で実行する
- メモリフットプリントが小さい＆超速い
すでにTwitterでは本番運用に投入してる
- Finagle/Thrift

Testing Containers with TestContainers: There and Back Again

Dockerなどを使ってインテグレーションテストをする場合に便利なTestContainersというライブラリを紹介するセッション。興味のあるセッションが見つからず苦し紛れで選択してみました。が、昼ごはん食べながら気を抜いて聞いてた＆あまり興味持ってなかった＆「テストとは〜」みたいな前置き話が長くて小難しく聞こえた、のでメモはあまり取ってません。

development, production, integration-testで環境が違うの大変
そこでDocker!
でも、内部ポートが毎回違うとか大変なことがある(?)
そこでTestContainers
- (コンテナのAPIを隠蔽したライブラリっぽい雰囲気)
- (コンテナクラスを使って、コンテナの設定/挙動や相互作用をコントロールできるようだ)
- (docker-composeであまり困ってないけど)
Spockサポートはこれから (?)
- (と思ったら誤解だったらしく、すでに普通にSpockで使えますよ、とTwitterで教えてもらいました)

TestContainers: Integration Testing Without the Hassle

https://www.slideshare.net/arhan/javaone-2017-testcontainers-integration-testing-without-the-hassle

なぜか2連続でTestContainersのセッションがあったのですが、ついうっかり聴講しました。内容的には重複しているというか、むしろこっちの方がわかりやすくて、こっちだけでよかった感があります。おかげでだいぶ理解できた気がします。

ユニットテストだけではなく、インテグレーションテストも重要だよね
- (文脈的に、インテグレーションテスト＝NWやノード構成を含めた環境上でのシステムテストを指しているっぽい雰囲気)
でも、インテグレーションテストには問題もある
- 時間がかかる
- セットアップが大変
インテグレーションテストに求められる6つのこと
- Reproducible environment
- Both for development and CI
- Isolated
- As real as possible
- Cross-platform
- Easy to set up, use & maintain
そこで、docker＆docker-compose!
- but
  - サーバのポート番号がdocker-compose.ymlにハードコードされる
  - テスト実行時に別途起動しないといけない
そこで、TestContainers!
- 複数のコンテナをプログラマティックにコントロールｄ家いるので、片方が死んでいるときのテスト、とか色々環境を変えつつテストできる
- 外部のdocker-compose.ymlをそのまま使うこともできるし、APIからプログラマティックに設定もできる
挙動イメージ
- インストール済みのdocker環境を見つけて、
- docker-composeを使ってコンテナを起動して、
- テストを実行して、
- テスト終了時にコンテナも終了する
ポート番号問題の解決
- コンテナの内部ポートをexposeするポート番号は空いているところを自動的に使ってくれる
- Container#getMappedPort()で実際にexposeされたポート番号が取れる
MockServerContainerを使うと任意のサーバのモックを実装できる
Javaagentのバイトコード変換で色々できる
- JettyHandlerに介入して、独自ヘッダを入れるようにしたり
Q&A
- Q: コンテナの起動コストは？
  - A: どのイメージを使うかによります。
- Q: docker in dockerの環境で使える？
  - A: yes. ドキュメントに書いてます。

Jump-start Your Microservices Development with Java EE

とりあえずJava EE系の何かを聞いてみようぐらいのモチベーションで入ってみました。混んでいた＆集中力が低下していたので、内容はあまり頭に入っていない＆メモがありません。

どうやら、EclipseのMicroProfileに関する紹介セッションだった雰囲気。

マイクロサービスアーキテクチャに最適化したJavaを実現するための「MicroProfile」、Eclipseの正式プロジェクトに
- http://www.publickey1.jp/blog/17/javamicroprofileeclipse.html

Best Practices for Developing and Deploying Java Application with Docker

https://www.slideshare.net/EricSmalling1/best-practices-for-developing-deploying-java-applications-with-docker

開発時や本番運用でDockerコンテナ上でJavaアプリケーションを実行する場合のベストプラクティスを紹介するセッション。具体的なパラメータは参考になるところもありましたが、あまり目新しいものはなかったので、メモは省略。

Building and Testing Java 9 Applications with Gradle

Cedric氏による2つ目のGradleセッション。 Jigsaw対応のプロダクトをGradleでビルドする方法の説明です。

現状ではまだGradle側のJigsawサポートも限定的で、相当なバッドノウハウを駆使しないとビルドができないようです。正直、ややこしいわ＆めんどくさいわで、相当ツラそうな感じです。最初はメモを取ってましたが「色々大変そう」「実際に手を動かす時に資料を見ればいいか」という気持ちになり後半いい加減です。

Jigsaw
- Reliable config --- "Good-bye classpath"
- Strong encupsulation --- "Good-bye com.sun"
- 移行時の注意
  - 2つのモジュールが同じパッケージをexportできない
  - 2つのモジュールが同じパッケージを内部パッケージとして持ってもいけない
GradleのJigsaw対応状況
- modulepathは未サポート
- Findbugsとかいくつかのプラグインが動かない
- ボトムアップで頑張っていくしかない
Gradleを使ったプロダクトのJigsaw対応のサンプル
- 課題
  - テストでのモジュールの依存関係が問題になる
    - loadClassしたらモジュール内のprivateなクラスもロードできる？
  - Gradleのapi/implementationコンフィギュレーションとJigsawのrequiresなどの依存性定義をうまく合わせる必要がある
- モジュールを今のGradleでビルドするにはトリッキーなバッドノウハウが必要
- テストはコンパイルでmainｍジュールに結合(patch)するのが楽＆早い
- テスト実行時にALL-MODULE-PATH
- (......色々面倒なことはわかった......)
実験的にJigsawプラグインを作ってみた
- クラスパスを強引にモジュールパスとして扱う(?)
Multi-release JAR
- Java 8/9のそれぞれで動くJARを生成するには、さらに色々仕込みが必要
  - 1つのJARないに別のターゲットのクラスを共存できる(?)
- (......まだまだ色々地獄だなぁという印象.....)
Minimal Runtime Image
- jlinkを使って最小限の実行イメージを作る