翌日の最終日(Day-5)はMariottホテルの会議室がセッション会場となるので、Moscone Westに通うのはこの日が最後です。 そろそろ終わりもみえてきて、並行して会場撤収なども始まるので、この辺りからだんだん寂しい雰囲気が漂い始めます。
Polyglot Adventures for the Modern Java Developers
モダンなJava開発プロジェクトを進めるために色々な言語を適材適所で使おう、という言語/ツールの紹介セッション。
- どの言語がベストというのはない。それぞれが特定の領域で強みを持っている、というだけ
- だから、適材適所で臆せずに混ぜ込んで使おう
- Setup-as-code
- シェルスクリプトよりも、Gradleタスク/Groovyが便利
- Build-as-code
- Mavenは良い。ただし、Gradleは100倍速い(?)
- Gradleはとても柔軟で、なんでもビルドできる
- 色々な言語を混ぜ込んだプロジェクトでもビルドが簡単
- Mavenは良い。ただし、Gradleは100倍速い(?)
- Main-as-code
- Frontend-as-code
- JavaScript一択
- TypeScript or (ECMAScript2015 + Babel)
- node + npm + webbpack
- JavaScript一択
- Test-as-code
- Pipeline-as-code
- Jenkins 2からJenkinsfileにGroovy DSLでかけるようになった便利になった
- Infrastructure-as-code
- Documentation-as-code
- Asciidoc + AsciidoctorJ + Gradle
- Architecture-as-code
- Presentation-as-code
- 「色々な言語やツールを使おうとすると学習コストがーという人がいるけど、実際やってみたら確かにそういう面もあるけど、トータルでハッピーでしたよ」
How Languages Influence Each Other: Reflections on 14 Years of Apache Groovy
我らがGroovyのProject Lead(Apache配下になってからは正確にはPMC Chair)であるGuillaume Laforge氏による、Groovyが誕生してから14年間における、他の言語との影響の相互作用について紹介するセッション。 なお、あくまでセッションメモなのでそれは事実と違う！などクレームはご遠慮ください。
- Groovy
- Groovyが他の言語から受けた影響
- Groovyから他の言語に与えた影響
- 言語同士はインスパイアしあう関係にある
- パーフェクトな言語はない
- でもみんな改善し続けてるよ
- Q&A
- Q: Groovyのswitchは、Java 7でやっと対応したString以外にもなんでもマッチングできて便利だけど、あれが各言語でのパターンマッチングに影響を与えたのかな？
- A: わかりません。ちなみに、Groovyでもここ10年くらいパターンマッチング実現しようと頑張ってるけど、全然完成してないです。
- Q: GroovyのJava 8シンタックスへの追随はいつになる？
- Q: Project Amberとかで、6ヶ月ごとに新しいシンタックス出てきたら追随大変じゃない？
- A: わかりません。まあ、新しいシンタックスへの対応はすぐには難しいかもだけど、動かすこと自体はできるんじゃないかと(よく聞き取れず)
- Q: データサイエンス分野ではPythonが大人気だけど、なんでGroovyはその分野で使われないの？
- A: (よく聞き取れず)
- Q: Jigsaw対応はどうなってるの？
- A: これはかなりの難題です。Jigsaw対応第一弾は2.6としてリリース予定ですが、一応動くけど警告が出る、という段階です。完全な対応にはGroovy自体のモジュール構成を破壊的に変更しないといけません。なので、メジャーアップデートとなる3.0での完全対応を目指すことになるでしょう。その辺も含めて今まさに検討＆対応中です。
- Q: Groovyのswitchは、Java 7でやっと対応したString以外にもなんでもマッチングできて便利だけど、あれが各言語でのパターンマッチングに影響を与えたのかな？
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 (!!!!!)
- mapを1つ使ったコード
- npm, ruby, node, scalaとかもサポート
- ineroperableなので、JavaScriptからJavaやRなども呼べる
- Rを呼ぶ場合、初回は裏でRプロセスを起動するので遅いけど、2回目以降は速くなる
- JavaScriptの場合、Chromeの開発者ツールでDebugできる
- (仕組みよくわからず)
- Visulal VMが同梱されてる
- SubstrateVM
- すでにTwitterでは本番運用に投入してる
- Finagle/Thrift
Testing Containers with TestContainers: There and Back Again
Dockerなどを使ってインテグレーションテストをする場合に便利なTestContainersというライブラリを紹介するセッション。 興味のあるセッションが見つからず苦し紛れで選択してみました。 が、昼ごはん食べながら気を抜いて聞いてた＆あまり興味持ってなかった＆「テストとは〜」みたいな前置き話が長くて小難しく聞こえた、のでメモはあまり取ってません。
- development, production, integration-testで環境が違うの大変
- そこでDocker!
- でも、内部ポートが毎回違うとか大変なことがある(?)
- そこでTestContainers
- 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にハードコードされる
- テスト実行時に別途起動しないといけない
- but
- そこで、TestContainers!
- 挙動イメージ
- インストール済みのdocker環境を見つけて、
- docker-composeを使ってコンテナを起動して、
- テストを実行して、
- テスト終了時にコンテナも終了する
- ポート番号問題の解決
- コンテナの内部ポートをexposeするポート番号は空いているところを自動的に使ってくれる
Container#getMappedPort()で実際にexposeされたポート番号が取れる
MockServerContainerを使うと任意のサーバのモックを実装できる- Javaagentのバイトコード変換で色々できる
- JettyHandlerに介入して、独自ヘッダを入れるようにしたり
- Q&A
- Q: コンテナの起動コストは？
- A: どのイメージを使うかによります。
- Q: docker in dockerの環境で使える？
- A: yes. ドキュメントに書いてます。
- Q: コンテナの起動コストは？
Jump-start Your Microservices Development with Java EE
とりあえずJava EE系の何かを聞いてみようぐらいのモチベーションで入ってみました。 混んでいた＆集中力が低下していたので、内容はあまり頭に入っていない＆メモがありません。
どうやら、EclipseのMicroProfileに関する紹介セッションだった雰囲気。
Best Practices for Developing and Deploying Java Application with Docker
開発時や本番運用でDockerコンテナ上でJavaアプリケーションを実行する場合のベストプラクティスを紹介するセッション。 具体的なパラメータは参考になるところもありましたが、あまり目新しいものはなかったので、メモは省略。
Building and Testing Java 9 Applications with Gradle
- 資料: https://melix.github.io/javaone-2017-jigsaw/#/
- GitHub: https://github.com/melix/javaone-2017-jigsaw
Cedric氏による2つ目のGradleセッション。 Jigsaw対応のプロダクトをGradleでビルドする方法の説明です。
現状ではまだGradle側のJigsawサポートも限定的で、 相当なバッドノウハウを駆使しないとビルドができないようです。 正直、ややこしいわ＆めんどくさいわで、相当ツラそうな感じです。 最初はメモを取ってましたが「色々大変そう」「実際に手を動かす時に資料を見ればいいか」という気持ちになり後半いい加減です。
- Jigsaw
- Reliable config --- "Good-bye classpath"
- Strong encupsulation --- "Good-bye com.sun"
- 移行時の注意
- 2つのモジュールが同じパッケージをexportできない
- 2つのモジュールが同じパッケージを内部パッケージとして持ってもいけない
- GradleのJigsaw対応状況
- 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ないに別のターゲットのクラスを共存できる(?)
- (......まだまだ色々地獄だなぁという印象.....)
- Java 8/9のそれぞれで動くJARを生成するには、さらに色々仕込みが必要
- Minimal Runtime Image
- jlinkを使って最小限の実行イメージを作る
本日のディナー
JavaOneチケットに含まれる今年のOracle主催パーティは、メジャーリーグのサンフランシスコ・ジャイアンツの本拠地であるAT&Tパークでの野外ライブでした。 以前はトレジャーアイランドでしたが、昨年度からAT&Tパークになったそうです。
普通に野球の試合があるとき用の売店で、無限ホットドッグ・ナチョス・ビールが振る舞われます。
おまけ
セッションの合間に会場をうろついてたDukeを発見して初のツーショット記念写真の撮影に成功しました(photo taken by skrbさん)。
