VSCode に java.configuration.runtimes を自動設定する拡張機能
VS Code 拡張機能 Java Extension Pack Auto Config の Java 21 対応版をリリースしました。この拡張機能には java.configuration.runtimes 自動設定を含む以下のような機能があり、JAVA_HOME などの設定が不要です。インストーラやパッケージャでインストールした JDK のバージョンアップなどでパスが変わった場合も、VS Code 起動時に settings.json が自動更新されます。
- Microsoft、Red Hat、VMware などの Java 拡張機能が付属
- 複数の JDK を自動設定、エラー修復、更新
- Maven や Gradle を自動設定、エラー修復、更新
- Java 開発用の自動デフォルト設定
- VS Code ターミナルで各バージョンの Java 実行可能
ReentrantLock を try-with-resources で安全に使う
Java 21で導入された仮想スレッドで、プラットフォームスレッドに影響を与えずに仮想スレッドに対してsynchronizedと同じ効果を得るために、ReentrantLockクラスの使用方法について投稿しました。通常のReentrantLockの使用方法は柔軟性がありますが、lock()とtryの間に処理を書くことができ、またfinallyにunlock()を書かないと不具合が発生する可能性があります。そのため、ReentrantLockを安全に使うための3つの方法を紹介しています。
- ReentrantLockをtry-with-resourcesで使用する方法
AutoCloseable対応の共通クラスを作成し、try-with-resourcesで使用します。これにより、自動的にアンロックされます。 - ReentrantLockをラムダで使用する方法
ラムダを扱える共通クラスを作成して、ラムダで使用します。これにより、アンロックがラムダ内で行われます。 - Lombokの@Lockedを使用する方法
Lombokのバージョン1.18.32で導入された@Lockedアノテーションを使用すると、ReentrantLockを簡潔に利用できます。
Spring Bootにおける仮想スレッドの対応や副作用についても記載しています。特に、Spring Bootでは3.2から仮想スレッドが利用可能であり、設定によってデーモンスレッドやアプリケーションの終了条件が変わります。また、Tomcatはバージョン11からリクエストの仮想スレッドをサポートします。
React、Vue、Svelte、Solid のレンダリング性能
様々な指標で多くの JavaScript フレームワークが計測されている GitHub js-framework-benchmark による処理時間 + レンダリング時間の公式総合結果。最も速い Vanilla JS (素の JavaScript) を 1 とした数値です。Vue は高性能とされているコンパイラ型の Svelte や Solid と比較しても意外？に速いようです。この結果からは性能に関しては React に対して Solid は圧倒的ですが、Vue に対して Svelte の優位性が薄い感じです。
表示速度は UX や SEO (Google 検索順位) に大きく影響します。現在の Google クローラーは CSR (クライアント側で JavaScript を実行してレンダリング) でコンテンツを評価できるため、Next や Nuxt などの拡張フレームワークによる SSR (アクセス時にサーバー側でレンダリング) や SSG (事前に静的サイト生成) でなくてもコンテンツ自体はほとんどの場合は認識されますが、方式に関わらず、処理 + レンダリング速度は重要です。Vercel、Cloudflare、AWS などの CDN で JS を実行するサービス CDN Edge も有用です。
拡張フレームワークの機能
| ベース | 拡張 | ファイルシステムルーティング | SSR | SSG |
|---|---|---|---|---|
| React | Next | ○ | ○ | ○ |
| Vue | Nuxt | ○ | ○ | ○ |
| Svelte | SvelteKit | ○ | ○ | ○ |
| Solid | SolidStart | ○ | ○ | ○ |
Eclipse と STS の違いは？
STS3 のときは、Eclipse に STS3 プラグインをインストールしたときと、ほぼ同じだったのですが、STS4 になり WTP が削除されたため、現在は STS と Eclipse + STS プラグインは結構異なります。ベースの Eclipse に Wild Web Developer が追加されましたがサーバー機能が無いため、WTP の代わりにはなりません。また、一般の開発者はあまり使わない重量級のプラグイン PDE (Eclipse プラグイン開発機能) が STS4 でも残っています。Tomcat 組み込みの Spring Boot jar しか使わない場合でも、画面を使用する場合、現在の STS は HTML 作成ウィザードなどがありません。
WebFlux と R2DBC の性能検証
Qiita に書きました。記事中からリンクしてる Spring Boot のドキュメントは公式サイトの日本語訳です。WebFlux だと 1 万リクエストが 1.7 秒でしたが、もっと速いと予想してました。スレッド数とかはデフォルトで十分そうだし、他の設定とか変更すると、もっと速くなるのかなー。
同時実行性能を求められる要件があり、Web MVC と WebFlux のパフォーマンスを比較しました。WebFlux は Web MVC と同じように Vue.js や Thymeleaf などを使用した画面や、REST API で使用でき、Reactor の継続渡しスタイル (CPS) と関数型プログラミングにより、非同期でノンブロッキングな処理を実現し、少ないスレッドでの並行処理と少ないハードウェアリソースでスケールが可能な Web スタックです。
WebFlux と合わせて R2DBC の DatabaseClient や WebClient のサンプルも少し載せています。
