#java

Javaの新しい節目として、JDK 27がGeneral Availability、つまり一般提供の段階に入った。今回は機能追加の派手さよりも、リリースが予定どおり安定版に着地したことに意味がある。開発途中の機能をどこまで積み上げたのか、そしてJava 27がどんな方向を向いているのかを確認するにはちょうどいいタイミングだと思う。とくに今回は、暗号、メモリ効率、並行処理、開発者向け観測機能といった、実運用に直結しやすい領域が目立っている。 OpenJDKのMark Reinholdは、Java 27の参照実装であるJDK 27が正式にGeneral Availabilityになったと告知した。今回GAになったのは、20 Augustに第2のRelease Candidateとして出された build 35 だ。そこからP1 bug、つまり最優先で対応すべき重大障害が報告されなかったため、その build 35 がそのままGA buildとして確定し、本番利用に向く状態になったという説明になっている。 公開先としては、OracleがGPL licensed OpenJDK buildを

この記事を読んでまず思ったのは、AIエージェントに便利なツールを与える話なのに、熱量の中心が「何をできるようにするか」ではなく「どう壊れにくくするか」にあるのがいい、ということだった。こういう話はついデモ映えする自動化に寄りがちだけれど、ここでは Bean Validation で入力を縛り、stateless なサービスとして置き、Goose から MCP 経由で呼ばせる。派手さはないけれど、現場で使うならそっちが先だよな、と思った。 特に引っかかったのは、AI agent に enterprise API や database migration を直接やらせるのは「brittle and dangerous」とはっきり書いているところだ。これはかなり実感がある。エージェントが賢くなっても、つなぐ先が雑なら事故る。だから「便利なラッパーを作る」より、「呼べる操作の形を狭くする」ほうが大事になる。`@Pattern` や `@NotNull` で customer ID を縛る例は地味だけれど、こういう地味さが本当に効く場面は多いと思う。 一方で、この記事は Part 1 らしく、ま

MCPの7月28日仕様更新で、HTTPベースの使い方がしやすくなった一方、攻撃面も増えた 特に気をつけるべきなのは、headerとJSON-RPC本文が食い違う「protocol confusion」 `_meta` に入る自由なJSONは便利だが、雑に扱うと injection やログ汚染の入口になる LLMはだまされやすいので、AI側だけで守るのではなく、Javaアプリ側で境界線を引く必要がある この記事では Quarkus の strict validation や security layer を使って、入口で弾く考え方が示されている MCP、つまり Model Context Protocol は、AIエージェントが外部ツールや社内データにつながるための共通ルールとして注目されている。元記事は、その最新版に入った変更が「便利さ」と引き換えに新しい危険も持ち込んだ、とかなりはっきり警告している。ここが面白い。新機能の話なのに、テンションはかなり防御寄りだ。しかも大げさではなく、実装者が本当に気をつけないといけないタイプの話だと思う。 ポイントは、MCPが stateful な接

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プログ