JJUG CCC 2019 Fallに参加してきました #jjug_ccc
- 10:00-10:45 Head toward Java 13 and Java 14 #ccc_c1
- 11:00-11:45 Jakarta EE: Today and Tomorrow #ccc_i2
- 13:30-14:15 運用を支えるためのログを出すにはどうするか? #ccc_m3
- 14:30-15:15 CLRのValueTypeを起点にProject Valhallaを覗いてみる #ccc_c4
- 15:45-16:30 Javaの起動速度といかに戦うか #ccc_g5
- 16:45-17:30 多言語対応の仮想マシンGraalVMが照らす未来 #ccc_i6
- 17:45-18:30 DIコンテナ入門 #ccc_g7
- 資料
10:00-10:45 Head toward Java 13 and Java 14 #ccc_c1
LINE Corporation KUBOTA Yuji @sugarlife
写真撮り忘れた・・・
java 13
- JEP 350:Dynamic CDS Archives
Class Data Sharing。共通的なクラスや文字列などを複数プロセスで共有する機能。
アプリケーション実行終了時にロードしたクラスを動的にアーカイブする
異常系も含めて全パターンを網羅しておく必要がある。
きしださんの「Javaの起動時間といかに戦うか」で、でてきたやつだ。
- JEP 354 Switch Expressions(Preview)
Switch文は、break、Switch式はyeild。
breakからyieldに変わり見分けがつくようになった。
他の言語だと遅延評価になるものあるが、Javaに関しては遅延評価ではない。即、値を返す。
- JEP 355: TextBlocks(Preview)
待望のヒアドキュメント
stripIndentの動作は、え?あれ???と思った。
java 14
- JEP 358 Helpful NullPointerExecptions
a[i][j][k] = b.l のようなのでも、どこでnullが発生したのかを明確にメッセージがでるようになった。
- JEP 359: Records(Preiew)
乱暴に言うと構造化されたtuplesのようなもの
Interface、Class、 recordの並びにくるもの
- JEP 361 Switch Expressions(Standard)
標準機能へ。現時点では大きな変更点はない。
OpenJDK Forks
Eclipse OpenJ9のJDK部分、AdoptOpenJDK、Red Hat OpenJDK、CentOS、Shenandoahプロジェクト、Red Hat、icedtea、ubuntu、しっかりOpenJDKの本家に追随しいてることを確認できた。(Amazonは知りません。)
感想
いよいよJavaでもヒアドキュメントが使えるようになる!
けど、 "JJUG¥nCCC¥n"になるのはどれでしょう?を見事に間違えた。
stripIndentの動作を理解してないので、試してみよう。
補足をブログで書いてくれると言ってた気がするが、どこ見ればいんだろう?
sugarlife's blog ? LINE Engineering?
11:00-11:45 Jakarta EE: Today and Tomorrow #ccc_i2
Dmitry Kornilov @m0mus on Jakarta EE: Today and
— Jim Grisanzio ☻ (@jimgris) 2019年11月23日
Tomorrow at the #JJUG_CCC #java @java pic.twitter.com/9cspjLLVYN
Jakarta EE 8
- release
- 仕様書
https://jakarta.ee/specifications
- 実装したプロダクト
https://jakarta.ee/compatibility/
Jkarta EE 9の計画
- 2019/12/9までにデリバリー計画が提出される
- 仕様書の更新
- javax.*からjakarta.* package名の変更
Bigbang or Incrementalはまだ決まってない
- Minimum Java SE version
8 or 11はまだ決まってない
- いくつかの仕様が非推奨になる
- 新しい仕様は加えない
例外としてJava SE 8から取り除かれた仕様
感想
Jakarta EE 8、Jakarta EE 9ともに新機能がないし、9の計画もまだだし、Jakarta EEの話を
聞くタイミングとしては寂しい時だったかな。
Jakarta EE 9でも、Java SE 8が最低バージョンになる可能性があるんだ。そこは11に上がるもんだと
思っていた。
13:30-14:15 運用を支えるためのログを出すにはどうするか? #ccc_m3
齋藤将也 https://twitter.com/wreulicke:title=@wreulicke
適切な量
- ログは保持、検索コストが高いので、多すぎず、少なすぎず
- INFOレベル以上で
- 必要なところに仕込む
意図の伝わる内容
いつ、誰が、どこで、何を どういう動作を行ったか その時のシステムの状態
アプリケーションの特性、要件、コンテキストに併せて、トラブルシューティングに必要な情報
- どのように対処するかも書くと良い
- 横通しで検索できる情報
例えば、トランザクションに紐づくID としてリクエストIDを出す 最初のServletFilterでMapped Diganostic Contextを使って付与する レスポンスにもリクエストIDも含める
検索しやすいログ形式
エラーログだけ、特定のAPIのログだけ、1トランザクションのログだけを検索しやすい
より良くするために
- テストではデバッガーではなくログで調査しよう
- ログを読もう
- 不足、不備を見つけたらログも改善していこう
- optimal logging も読もう https://testing.googleblog.com/2013/06/optimal-logging.html
- Optimal Logging の和訳 https://gist.github.com/wreulicke/faf56bd29c1efba76b0ea28ebf5644b8
感想
トラブルシューティングしてると、どうでもいいログはたくさん出てるのに
肝心なところでなぜ出さない!と思うことが多々ある。
自分で痛い目に合うと気をつけるだけど、痛い目に合わないために、ログのポイントをプロジェクトで
認識を合わせたほうがいい。
盲信せず、議論のたたき台としてはいいんじゃなかろうか。
14:30-15:15 CLRのValueTypeを起点にProject Valhallaを覗いてみる #ccc_c4
値型
メリット
- 間接参照ではないため、メンバーアクセスが高速
- スタックを使うので、メモリ確保が速い
- CPU近傍にデータを配置できる(可能性がある)
- GCの影響を受けない
デメリット
- 代入時には値の複製が生じる
- 型のサイズが大きいとき、複数のコストが大きい
- 継承や多態的な振る舞いを実装できない
Value Type(Inline Class)
- 「class」と同じように「inline classs」で記述できる
みんな大好きjavapすると見慣れないdefaultvalue、withfieldという新たなバイトコードを確認できる
- Object Identityを持たないので最適化しやすい
できるだけまとめて、CPUの近くのキャッシュに置きたい
- Javaが.NETの知見を取り込んでValueTypeを検討してる
例えば、ユーザー定義のデフォルト値は許可しない
マイルストーン
- L1~L100あるマイルストーンのうち、今はまだL2。
プロトタイプの開発、検証を繰り返しているため
- 今は、JDK14ベースのものなら遊べる
いつでるの?
次のLTS(Java 17)は難しそう、次の次のLTS(Java 23)ならどうにかなるかも!?
感想
先はまだまだ長そうだ。
デメリットよりもメリットを享受できるのはどのようなプロダクトだろう?
.NETにも興味をもっと持ってみよう。
C# 8.0のnull許容参照型を学ぶならこれがよさそう。
https://www.slideshare.net/ufcpp/c-80-null
西川さんってマイクロソフトの人になってたのか。
15:45-16:30 Javaの起動速度といかに戦うか #ccc_g5
LINE Fukuoka きしだ なおき @kis
きしださん登壇5分前に会場入りするファンサです。YAZAWAかな? #jjug_ccc pic.twitter.com/PN1JrKz2Cz
— 941 (@941) 2019年11月23日
起動速度を求める理由
アプリケーションサーバであれば、起動しっぱなしだったので起動速度は求められなかった。 しかし、マクロサービスでの負荷に合わせた伸縮やサーバーレスでの使われ方だと起動速度が 重要になる。
アプローチ
- 使いまわす
- あらかじめ行っておく
GraalVM
- GraalVMの話のときは、JIT版なのか、AOT版なのかを区別しないと話が噛み合わなくなるので注意が必要。
まとめ
- 起動時間、メモリの削減でNative imageが圧倒的に速いし注目されているが、まだ安定していない。
- トレードオフとして、スループットの劣化、変更しやすさ、使いやすさを失ってしまう。
- Javaに入っている標準機能でもある程度起動速度とメモリも削減できるので、こちらに着目してもいいのではないか
感想
Java 8と比較して、Java 13で起動速度早くなってるのね。
App CDSでさらに速くできる。
native imageはトレードオフとの兼ね合いだとなるので、当面使う場面には出くわさなさそうだ。
16:45-17:30 多言語対応の仮想マシンGraalVMが照らす未来 #ccc_i6
ヤフー株式会社 阪田浩一 @jyukutyo
GraalVMとは
- あらゆる言語の実行環境となれる能力と機能があるユニバーサルVM
- ビジョン:パフォーマンスを犠牲にせず、言語間の抽象化をする
GraalVMの構成
GraalVM JITコンパイラ(以前はここをGraalと言っていた) 以前、GraalとGraalVMってどういう関係だっけ??混乱してた。
GraalVMで動作する言語
そうそうこのイメージ。
ネイティブイメージの生成
なんでネイティブイメージの生成が出てきのか? それは、Oracle Databaseのため。 GraalVMを組み込めば、Javaはもちろん他の言語も使える。 が、そのまま組み込むにはJVMのサイズの大きさ、初期化処理の遅さ、メモリ使用量の大きさがネックだった。 そこでnative image化。 Oracle Database MLE(Multilingal Engine) MySQLもMLE Pluginに取り組んでいる
ネイティブイメージが適切なケース
- FaaS
- クラウドで実行する大規模アプリケーションでのリソース削減
- 頻繁にリリース(再起動)するマイクロサービスのようなアプリケーション
起動速度とビルド速度のトレードオフ
- 万能な技術は存在しない、技術はトレードオフ
- 起動時に行うことを生成時にに行うのでビルド時間が長くなる
- Hello Worldで1分超かかる
感想
GraalVMがなんでネイティブイメージの生成と関係してくるのか結びついてなかった。
Oracle Database MLE(Multilingal Engine)は聞いたことあったけど、そこから生まれたのか。
なるほどね。
17:45-18:30 DIコンテナ入門 #ccc_g7
TIS株式会社 うらがみ @backpaper0
写真NG
https://backpaper0.github.io/ghosts/dicontainer/#1
まとめ
- DIとはごく普通のクラス設計の手法
- DIコンテナは依存関係を考慮したインスタンス構築を助けるもの
- ボイラープレートなインスタンス構築コードを省略できる
- ついでにスコープとAOPが付いてきて嬉しい
- コンストラクタインジェクションがオススメ
感想
DIコンテナとはなんぞや!と言われたらこれ読んでで済むね。
裏面も気になる!