経緯
いつも参加しているJJUGが開かれるので参加
今回は、現地開催のみだったので、足を運んだ
公式サイト
JJUG CCC 2023 Fall（現地開催のみ） - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper
参加したセッション
本当は、午前から参加する予定だったが、前日の夜にコーラ飲んだせいで、なかなか寝付けず、起きたら10時だったので、午前は諦めた
- JDK 21 へようこそ
- Gatlingによる負荷テスト入門
- データ指向プログラミングの真実をお話しします
- String Templateによる文字列補間
参加セッションメモ
★ありのところは、自分の感想
JDK 21 へようこそ
- Loom/Amberがウエイト大きい
- Loomの注目度が高め
jep 439 ZGC
21以降だったら世代別を使え！！
- オブジェクトは生存期間が短い物が多い
- young領域を頻繁にコレクトすることで効率化している。
生存確認（＋前のサイクルの再マッピング処理）
- マーキング
- 移動
Minor Collection -> young領域が対象
GCの実装に世代別とシングルスペースの実装がある 時期は未定だが、シングルスペースのGCは削除される予定
JEP444 virtual thread
同期処理
- プログラマーには優しいが、ハード的には嬉しくない
- トラブルシューティングが比較的楽
非同期処理
- プログラマーに優しくないが、ハード的には嬉しい
- トラブルシューティングが面倒
Javaのスレッド
- OSスレッド
- 高いメモリ使用量
- 全てのユースケースに対応されているため、局所化されていない
- 一部を非同期化しにくい
- トラブルシューティングが面倒になる
バーチャルスレッド
- ランタイムによってスレッドを管理する
- スタック領域を節約できる
- スケジュールのアルゴリズムもjavaに最適化されたものが使えるようになる
- 利用すると１０倍くらい省エネになる
- ハード、開発者の両方からみてもやさしい。
project amber
複数のバージョンでリリースされているが、関連性がそれぞれ高め
おさらい
パターンマッチング
- instanceofでキャストが不要になる
- その場合、識別子の指定が必要になる
- キャスト名をたまに間違えることがあるので積極的に使うべき
- instanceof -> nullチェックもしてくれる
record class
ボイラーテンプレのコードが不要になる オブジェクト比較も問題ない
java21での追加内容
switchのパターンマッチング
- caseに型を指定できるようになった
- オブジェクトの指定が可能になった
- caseの指定順序が重要になってしまった
- オブジェクトの継承関係・実装関係が影響してくる
- 例外の関係に近い問題が出てくる
- コンバイルエラーになる
- nullも利用できるようになった
- 該当するケースがない場合、defaultにない／当てはまらない可能性がある場合、コンパイルエラーが出る
- シールドをうまく活用する
- オブジェクトの継承関係・実装関係が影響してくる
- when 節
- 詳しい条件を指定できるようになった
★ 汎用的に使えるようになったが、型をうまく使えないと効率化させるのが難しくなった感じがする
jep432 シーケンスコレクション
コレクションに共通機能が追加された
★以前調べた内容をそのままだったので、下記参照
Gatlingによる負荷テスト入門
★ガトリング => 武田観柳？？
メリット
- 負荷試験、モニタリングもやる
- 中間報告出せる
- 実行終わるとレポート出せる
★gattling使ってみる
負荷テスト
負荷をかけたときの状態を知るためにする
負荷の観測
- 見れるようにしておく
- 構成図書いてあたりをつける
- どこの何が見たいのか考える
- まずはアウトプットする
- 分からなくても、後で考察するときに使える
- 設計課題が見つかる
- 負荷になっているかの指標も必要
- アクセスログだすなどのアクションにつながれば、負荷テストは成功
ApacheBench
- 簡易的なら向いてる
- 露払いくらいならできる
負荷テストの道具の条件
- シナリオ組める
- 負荷の調整できる
負荷テストに必要なこと
- 本番の構成などの情報が必須
- 負荷テストの定義決めておく
ガトリング
スレッドではなく、メッセージングベース
★環境作ろうと思ったが、面倒になった。。。
★とりあえず、ApatchBenchを動かしてみることまではやった。
★試した内容は、下記記事参照
データ指向プログラミングの真実をお話しします
Project Amber
- データサイズが小さいものも使うようになった
- 全部Javaで作らなくなった
- オブジェクトではなくデータのやりとりが増えた
データ指向プログラミングから
- コードとデータの分離
- 汎用データ構造でデータを表現する ⇨ 型を使わない？？
- データはイミュータブル
- データ表現からデータスキーマを切り離す
データとは何か？
- データと情報と知識の違い
- データ：観測、収集した物
- 情報：データに解釈を加えたもの
- 知識：情報をもとに判断したもの
データと情報
構造の違いではない
区別する方法
- 構造を変える
- 名前を変える
解釈の実装をどこでするか？
関数ないで、データを解釈しながら使う
メリット
- 解釈の自由度が高い
デメリット
- 解釈が関数ごとに違う場合がある
- 解釈にはコードを読む必要がある
cloujerが元になっている。colujerではspecで解釈違いを防いでいる
Amberでは、型で解釈させる
- 仕様を変える時に影響範囲が分からなくなる可能性あり
- カプセル化の破れ
★個人的な解釈
★DBにあるもの-> データ
★SQLで抽出したら->情報：オブジェクトにどうマッピングしているか
★ 命名が重要になってくる：名前＝情報になる
要件をどうやってモデリングして実装するかが重要
複雑さ
複雑を理解する
- データの解釈、振る舞いを分割する
- 分割したものを分割統治する
- 分割したら終わりではない
モデルの概念が明確になっていること
そのためには、分割が重要
例外とか不正値があると、分離ができないように感じるが、どう対処するべき？
いくつか派閥あり。型でやるなら前段階で判断して後続処理を行うようになるのがベターだと思う
String Templateによる文字列補間
jep459
変数を含んだ文字列結合のパターン - StringBUilder - String.format or Formatter - MessageFOrmat
内部での動き
どの形式も、煩雑になったり、変数との対応づけが分かりにくい
↓
簡単に書けて、間違いを起こしにくい方法が欲しい
↓
テンプレートを使った文字列保管が必要になった。でもテンプレートエンジンを使うほどでもない。もっと手軽で汎用的なものが欲しい
↓
StringTemplate登場
String Templates
文字列に変数・式を埋め込み、文字列補完を行う言語使用
StringTemplate.STR
- 文字列を生成する最も基本的なテンプレートプロセッサ
- static importせずとも使える
- テンプレート引数に複数行かけるが、おすすめはしない
- nullが入ってくると、nullの文字列が設定される
StringTemplate.FMT
StringTemplate.RAW
未処理のStringTemplate
StringTemplateの動作
- 要素を分割
- 文字列と値を別々にまとめる
- StringTemplate.ofが実行
- Processor.processがコールされる
文字列補完の危険性とカスタムテンプレート
Custom Template Processor
文字列保管の危険性
埋め込みをした結果、不適切な状態になる
安易に使うのは、危険。
対処するには、カスタムテンプレートで対応する
型による制限やバリデーションで対処する
感想
なんで寝坊してしまったんだ。。。
StringTemplateは、あまり興味を持てなかったが、使い方次第では化けそうだなと感じた。
gatling試そうとしたんだけど、ドキュメント読んで環境準備するのが辛い。。。
ApacheBencheは簡単だったのに。。。
なにか、前提知識が足りてない気がする。
バーチャルスレッドは、やはり有能そうだな。
どこかでキャッチアップしたいと思いつつ、なぁなぁになってしまっている。
どうにかしたいと思うが、試せるかどうかは別の話。
足りないものや興味が出たものがいくつかあったので、収穫はあったかなと思う。
問題は、それを突き詰めて調査したり、ものにできるかどうかだな。。。
今、メンタル的にポジティブになれないのと、そこまで活力がでないので、厳しい気がする。
そう言っても、このイベントに出てくるだけの気力は、あった。
