JJUG CCC 2019 Fallに参加してきました #jjug_ccc

JJUG CCC 2019 Fall
JJUG CCC 2019 Fall





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に関しては遅延評価ではない。即、値を返す。

  待望のヒアドキュメント
  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 blogLINE Engineering





11:00-11:45 Jakarta EE: Today and Tomorrow #ccc_i2

Oracle  Dmitry Kornilov @m0mus

Jakarta EE 8

  • release

https://jakarta.ee/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
f:id:orangeclover:20191126232802j:plain

適切な量

  • ログは保持、検索コストが高いので、多すぎず、少なすぎず
  • INFOレベル以上で
  • 必要なところに仕込む
    • good
      • システム間通信のリクエスト、レスポンス
      • 業務の関心ごとの対する重要な変更   例えば決済サービスならその決済がどうなったか
    • 重要なロジックの分岐点やその分岐に至った条件

    • bad

      • 関数の入り口
      • AOPで出すと多くなりすぎるし、AOPだけだと業務観点が不足する

意図の伝わる内容

いつ、誰が、どこで、何を どういう動作を行ったか その時のシステムの状態

アプリケーションの特性、要件、コンテキストに併せて、トラブルシューティングに必要な情報

  • どのように対処するかも書くと良い
  • 横通しで検索できる情報

例えば、トランザクションに紐づくID としてリクエストIDを出す 最初のServletFilterでMapped Diganostic Contextを使って付与する レスポンスにもリクエストIDも含める

検索しやすいログ形式

エラーログだけ、特定のAPIのログだけ、1トランザクションのログだけを検索しやすい

より良くするために

感想

トラブルシューティングしてると、どうでもいいログはたくさん出てるのに 肝心なところでなぜ出さない!と思うことが多々ある。
自分で痛い目に合うと気をつけるだけど、痛い目に合わないために、ログのポイントをプロジェクトで 認識を合わせたほうがいい。
盲信せず、議論のたたき台としてはいいんじゃなかろうか。







14:30-15:15 CLRのValueTypeを起点にProject Valhallaを覗いてみる #ccc_c4

日本マイクロソフト株式会社 西川彰
f:id:orangeclover:20191126232826j:plain

値型

  • メリット

    • 間接参照ではないため、メンバーアクセスが高速
    • スタックを使うので、メモリ確保が速い
    • CPU近傍にデータを配置できる(可能性がある)
    • GCの影響を受けない
  • デメリット

    • 代入時には値の複製が生じる
    • 型のサイズが大きいとき、複数のコストが大きい
    • 継承や多態的な振る舞いを実装できない

Value Type(Inline Class)

  • 「class」と同じように「inline classs」で記述できる

  みんな大好きjavapすると見慣れないdefaultvalue、withfieldという新たなバイトコードを確認できる

  • Object Identityを持たないので最適化しやすい

  できるだけまとめて、CPUの近くのキャッシュに置きたい

  • Javaが.NETの知見を取り込んでValueTypeを検討してる

  例えば、ユーザー定義のデフォルト値は許可しない

マイルストーン

  プロトタイプの開発、検証を繰り返しているため

  • 今は、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

起動速度を求める理由

アプリケーションサーバであれば、起動しっぱなしだったので起動速度は求められなかった。 しかし、マクロサービスでの負荷に合わせた伸縮やサーバーレスでの使われ方だと起動速度が 重要になる。

アプローチ

  • 使いまわす
    • JITのためのプロファイル
      • Alibaba Dragonwell -JWarmup
    • JIT結果
      • OpenJ9
      • Azul Zing - Falcon JIT
  • あらかじめ行っておく

GraalVM

  • GraalVMの話のときは、JIT版なのか、AOT版なのかを区別しないと話が噛み合わなくなるので注意が必要。

まとめ

  • 起動時間、メモリの削減でNative imageが圧倒的に速いし注目されているが、まだ安定していない。
  • トレードオフとして、スループットの劣化、変更しやすさ、使いやすさを失ってしまう。
  • Javaに入っている標準機能でもある程度起動速度とメモリも削減できるので、こちらに着目してもいいのではないか

感想

Java 8と比較して、Java 13で起動速度早くなってるのね。 App CDSでさらに速くできる。 native imageはトレードオフとの兼ね合いだとなるので、当面使う場面には出くわさなさそうだ。





16:45-17:30 多言語対応の仮想マシンGraalVMが照らす未来 #ccc_i6

ヤフー株式会社 阪田浩一 @jyukutyo
f:id:orangeclover:20191126232851j:plain

GraalVMとは

  • あらゆる言語の実行環境となれる能力と機能があるユニバーサルVM
  • ビジョン:パフォーマンスを犠牲にせず、言語間の抽象化をする

GraalVMの構成

f:id:orangeclover:20191126232352p:plain GraalVM JITコンパイラ(以前はここをGraalと言っていた) 以前、GraalとGraalVMってどういう関係だっけ??混乱してた。

GraalVMで動作する言語

f:id:orangeclover:20191126232512p:plain

そうそうこのイメージ。

ネイティブイメージの生成

なんでネイティブイメージの生成が出てきのか? それは、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コンテナとはなんぞや!と言われたらこれ読んでで済むね。 裏面も気になる!





資料