先日、JJUG Java生誕25周年記念イベントに参加しました。今回はオンライン開催。簡単に所感をまとめます。
所感
JJUG CCC 2020 Spring が中止になり、代わりに開催されたイベントです。Java 生誕25周年。セッションは総会を含めて5本でしたが、幅広い内容で面白かったです。
しかし、IDEの位置付けについてここまで深く考えられるもんなんですね。納得感のある内容でした。今のプロジェクトで使ってる Eclipse めっちょ古いからバージョンアップしなければ...。まずはバージョンアップできるようにプラグインとか周辺のツールを整理するところから。
Jakarta EE はパッケージ名の変更がインパクト大きそうだけど、YouTube のコメントを見てると意外とマイグレーションツールが提供されるっぽい？
あと、キャッシュの更新検知はプロダクト任せになるのかな。Infinispan は通知してくれるみたいだけど。結局、セッションにはユーザー情報とか更新頻度が低いものを入れるのがよさそう。
YouTube の URL はこちら。
以下、メモから抜粋。
Java 14 新機能を軽くまとめてみた
- Java 14
- 16 JEPs
- non-LTS (パッチは15リリースまで)
- 言語機能の標準化は3段階
- Incubator
- ライブラリ
- incubator モジュールとして import する必要あり
- Experimental
- Text Blocks (Preview 2)
- 15 で Standard になる予定
- 改行のエスケープ (
\) - スペース文字 (
\s)
- Switch Expressions (Standard)
- case 句に複数のラベルが指定可 (ステートメントも同様)
- アローを使うと
breakは記述不要 - 値を返すときは
yieldを使う yieldはキーワードではない (型名には使えない)
- Records (Preview)
- Sealed Classes (Java 15 で Preview)
- 継承するクラス/インタフェースを限定できる
- Switch 式で
defaultが不要になる- すべての case を処理したことをコンパイラ側で検知できるため
- Pattern Matching for instanceof (Preview)
- スマートキャスト
if (obj instanceof String s) {...}って文法として微妙な気がするのは自分だけだろうか...- 今のところバイトコードには無駄なところが多い模様
- Pattern with Switch
- switch でパターンマッチ
- 近いうちに入るかも？
- Deconstruction
- switch の case で Record を分解する
- 今のところ入る予定なし
- JFR Event Streaming
- ファイルにダンプしたデータはストリーミングで見るには不便
- Event Streaming ではイベントとして処理できる
- 監視に使いやすい
- JFR はそろそろ OpenJDK 8 にパックポートされる模様
- Foreign Memory Access API (Incubator)
- ヒープ外のメモリを扱う
- これまでは Unsafe が使われていた
@PreviewFeature- Packaging Tool (Incubator)
- https://qiita.com/nowokay/items/ec85d97a7cecaaac8123
if (obj instanceof String s) { ... } ってちょっと文法として微妙じゃない？なんか代入してる感がないというかなんというか... / "JEP 305: Pattern Matching for instanceof (Preview)" https://t.co/xsqEkFZJHG
— kntmr (@knt_mr) 2020年5月23日
IDE起点で2020年代の開発環境を眺めてみる
- たくさんのツールを使うのは高コスト
- ツールを組み合わせると取りこぼすものがある
- これらをシームレスに使えるようにするためにIDEがある
- いろいろなツールを使うことより開発そのものにリソースを割きたい
- 開発で使うツールは開発を邪魔するものであってはならない
- ただし、ツールを蔑ろにしていいわけではない
- IDEの役割は開発を容易にすること
- IDEは開発者のためにある
- 開発対象のアプリケーションがIDEに依存してはいけない
- IDEはビルドツールの設定を読み込んで使う
- IDEはビルドツールに依存させる
- IDEの独立性を高める☆
- IDEはなんでもいいというところまで持っていく
- アプリケーションに影響を与えるものはIDEに設定しない
- IDEからビルドツールを使うときにIDEバンドルのJDKは使わない
- アプリケーションに影響を与えるから☆
- IDEを使うならエラーを出したまま放置しない
- IDEが出している警告も個人的には残したくない...
- いざというときにプリミティブなツールが使えると安心
- IDEの新規プロジェクト作成とかクラスパス設定とかは今はやらない
- フォーマッタを切り離したい
- 言語にフォーマッタが付いてるといい
- IDEのバージョンアップは積極的にするべき☆
Jakarta EE / MicroProfile を利用したクラウドネイティブアプリの開発
www.slideshare.net
- J2EE 時代はビジネスニーズに応えることをメインにしていた
- 開発効率の重要性は高くなかった
- 開発効率を重視 ⇒ Java EE
- Oracle から Eclipse Foundation に寄贈 ⇒ Jakarta EE
- Java EE 準拠を名乗るためには高額な TCK を通す必要がある
- Jakarta EE
- Jakarta EE 9 (2020/06)
- Jakarta EE 10 には大きな変更がある予定
- MicroProfile 3.3
- GraphQL 対応
- MicroProfile 4.0
- Jakarta EE パッケージの対応
- https://start.microprofile.io/
- MicroProfile + サーバーサイドレンダリング
- テンプレートエンジンはある？
- レンダリング系は MicroProfile の仕様には含まれていない
システムのモダナイズ 落ちても良いアプリの作り方
www.slideshare.net
- スケールアウトしたのに負荷が偏る
- スケールインで情報を持っていたノードが消えた
- システムの可能性を高めるには
- 耐障害性向上
- スケールアウト
- クラウドを使っているとそれ以上耐障害性を上げられなかったり
- ステートレスなアプリケーション ⇒ スケールアウト
- ステートフルなアプリケーション ⇒ ？
- ステートの取り扱い
- DB/インメモリに読み書き
- 透過的に使う ⇒ HTTPセッション
- なぜHTTPセッションを使うのか☆
- HTTPセッションに入れていいもの☆
- Connection や Thread は Serializable ではない
- ステートはどのように保持されるか☆
- ファイル(共有ストレージなど)/DBに置く場合、複数のアプリでステートを共有できる
- アプリがステートを持つメリデメ☆
- ステート数が増加してヒープを逼迫するとGCによる停止時間が増えてレスポンス遅延に
- ファイル/DBがステートを持つメリデメ☆
- ステートフルで可能性を担保するために重要なこと☆
- ステートをどこで持つか
- リクエストをどう振り分けるか
- セッション外部化
- DBにステートを持たせる
- 全体はステートレスになるもののレスポンスは遅い
- 外部ストアの性能劣化にはニアキャッシュを使う
- ニアキャッシュ
- よく使うセッション情報をアプリ上にキャッシュする
- ネットワークやディスクアクセスを減らす
- スティッキーセッション
- アプリが落ちるとセッションは消える (運用で落とす場合も同様)
- オートスケールできない？
- 負荷が偏る可能性あり ⇒ 時間を短くして分散しやすいように
- アプリが落ちるとセッションは消える (運用で落とす場合も同様)
- DBにゴミデータ残らないか？
- セッションの有効期限を設定する
- セッションには変更されない情報を入れるのが現実的？☆
- キャッシュの更新は？
