#java

Javaの世界で長年ほぼ伝説扱いだった Project Valhalla が、ついに JDK 28 に入ってくる見通しになりました。元記事は、このニュースを起点に「そもそも Valhalla って何なのか」「なぜこんなに時間がかかったのか」「JDK 28 で本当に何が入るのか」を、かなり丁寧にたどっています。 個人的に面白いと思ったのは、Valhalla が単なる“高速化プロジェクト”ではないことです。もっと本質的には、Java の書きやすさと機械にとっての扱いやすさが、ずっとズレたままだったのを何とか揃えようとしている話なんですね。ここ、地味だけどかなり大きい。 Valhalla は、「クラスの書き心地」と「primitive のような効率」を両立させるための長期プロジェクト JDK 28 には JEP 401: Value Classes and Objects が入る見込み ただしこれは preview で、しかも最初の一歩 にすぎない 重要なのは、Java のオブジェクトが抱える 間接参照・メモリのばらつき・GC負荷 を減

Endive は、JVM native WebAssembly runtime、つまり「Javaの上でWebAssemblyを動かすための実行基盤」です。 いちばんの売りは、native dependencies や JNI が不要なこと。Javaの配布や運用がかなりラクになります。 Rust/C++系のWasm runtimeをJavaアプリに組み込むときの悩みどころである、配布の面倒さとJVMの安全性を外に出てしまう問題を減らそうとしています。 もともとは Chicory というプロジェクトが土台で、Dylibso からの流れを受けて Bytecode Alliance のプロジェクトとして進んでいます。 すでに interpreter、compiler、WASI対応、SIMD、tail call、threads、GC、multi-memory など、かなり広い範囲が進んでいます。 「JavaでWasmを使いたいけど、ネイティブ依存は増やしたくない」という人には、かなり面白い選択肢だと思います。 GitHubで公開されている

SonarQubeは、Javaコードを静的解析して、バグや脆弱性の候補を自動で見つけるツール 記事の例では、ハードコードされたAPI key を検出できたのが大きなポイント JenkinsなどのCI/CDに組み込むと、毎回自動でチェックできて抜け漏れが減る Quality Gate を設定すると、問題のあるコードはマージ前に止められる ただし万能ではなく、false positive（誤検知）や security hotspot の手動レビューも大事 個人的には、SonarQubeの価値は「検出」よりも「開発の流れに安全を組み込めること」にあると思う 元記事は、かなり現場感のある話から始まります。 あるチームがセキュリティ監査を受けたところ、支払い処理モジュールに重大な脆弱性が見つかりました。 しかも、ユニットテストも統合テストも通っていたし、コードレビューも一見きれいだった。 それなのに、監査で見つかったのはユーティリティクラスに隠れていたハードコードされたAPI keyだった、というわけです。 ここが非常に重要です。

OpenAPIは、APIの「設計図」みたいなもの Spring Bootでは `springdoc-openapi` を使うと、コードからOpenAPI定義を出せる ただし、手で保存する方法は面倒で、CIには向かない 記事の核心は「アプリを起動した状態で、MavenプラグインにOpenAPIを取りに行かせる」こと そのために `openapi` 用のSpring profile を分けているのがうまい CIでAPI仕様を自動生成できると、フロントエンド連携や契約テストがかなり楽になる この記事は、Spring Bootアプリから OpenAPI 仕様を自動生成し、それを CI pipeline に自然に組み込む方法を紹介しています。 まず前提として、OpenAPIはAPIの仕様を機械が読める形で表したものです。人間にとっては「このAPIはGETで、こういう入力を受けて、こういう出力を返す」と読めるし、ツールにとっては「クライアントコードを作るための材料」になります。 ここが大事で、OpenAPIはただのドキュメントではありません。 実際には次のような用途でかなり役に立ちます。

TypedMemory は、Java 25 以降向けの off-heap memory（Javaのヒープ外メモリ）を扱うライブラリ record をそのままメモリの型として使えるのが大きな特徴 Javaの FFM API（Foreign Function & Memory API）を土台にしている `get(index)` / `set(index, value)` のように、配列っぽく安全に読み書きできる レイアウト（メモリ配置）を自動で推論してくれるので、手作業の offset 管理がかなり減る ただし、experimental でまだ発展途上。今後仕様が変わる可能性はある `String` や `List<T>` のような参照型はまだ非対応で、対象はかなり「低レベル寄り」 この記事で紹介されている TypedMemory は、ひと言でいうと、 > Javaのrecordを、強い型を保ったまま off-heap memory にマッピングするライブラリ です。 これ、地味に見えてかなり面白いです。 普通のJavaプログ