💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

モダン Java 2026 — Java 25 LTS / Spring Boot 3.5 / Quarkus 徹底ガイド

2026 年の Java はもう「保守的なエンタープライズ言語」ではない。Java 21 LTS(2023 年 9 月)で仮想スレッドが GA になり、Java 25 LTS(2025 年 9 月)ではパターンマッチングが確定し、仮想スレッドは実質的にデフォルトの実行モデルになった。GraalVM 25 のネイティブイメージは Spring Boot 3.5 で一級市民となり、Quarkus 3.20 は Lambda や Kubernetes 上で supersonic / subatomic な起動時間を実現する。一方でメルカリ、LINE、NTT データ、楽天、そして韓国のトス・カカオペイといった大規模トラフィックのサービスは、いまもコアを Java / Kotlin / Spring で回している。本稿は 2026 年 5 月時点で、モダン Java エコシステム全体を一気に整理する。

1. 2026 年のモダン Java — Java 21 LTS が変えたこと、Java 25 LTS が締めたこと

時系列で並べるとこうなる。

- **Java 17 LTS(2021 年 9 月)** — Record、sealed クラス、`instanceof` のパターンマッチングが定着。多くのエンタープライズコードの基準。

- **Java 21 LTS(2023 年 9 月)** — 仮想スレッド GA、Record Patterns、Pattern Matching for switch GA、Sequenced Collections、Generational ZGC(preview)。**モダン Java の分岐点**。

- **Java 22(2024 年 3 月)** — Project Panama の Foreign Function & Memory API(FFM)GA、Unnamed Variables and Patterns、String Templates(preview)。

- **Java 23(2024 年 9 月)** — Markdown JavaDoc、Primitive Types in Patterns(preview)、ZGC のデフォルトモードが Generational に。

- **Java 24(2025 年 3 月)** — Compact Object Headers(preview)、Stream Gatherers、JEP 491 などの段階的改善。

- **Java 25 LTS(2025 年 9 月)** — **仮想スレッドのデフォルト推奨**(JEP)、Module Import Declarations(preview)、Pattern Matching for switch 最終安定化、JEP 470 PEM キーストア、Generational ZGC デフォルト、Compact Object Headers デフォルト。

要点は二つ。(1) 2026 年に新規構築する Java サービスは **Java 21 か Java 25 LTS** が標準で、Java 17 は保守モード。(2) 並行処理はもう「スレッドプールのチューニング」ではなく、**ブロッキング風のコードを書けば JVM が捌いてくれる**モデルが一般化した。リアクティブの「コールバック地獄」時代は終わった。

2. Java 25 LTS(2025.9)— 仮想スレッド default、パターンマッチング、Module imports

Java 25 LTS の大きな変化を 3 つ。

2.1 仮想スレッド(Virtual Threads)が実質デフォルト

Java 21 で GA になった仮想スレッドは、Java 25 LTS で「Synchronize Virtual Threads without Pinning」(JEP 491)などが安定化し、事実上 **新規コードのデフォルト**になった。基本 API。

// Java 25 — 仮想スレッドをそのまま使う最小例

Thread.startVirtualThread(() -> {

var response = httpClient.send(request, BodyHandlers.ofString());

log.info("got {}", response.statusCode());

});

// Executor 形式

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {

IntStream.range(0, 10_000).forEach(i ->

executor.submit(() -> fetchUser(i))

);

} // 自動 join

1 万件の同時 HTTP 呼び出しでも OS スレッドは数十本程度。JVM が carrier スレッド(= ForkJoinPool)上で仮想スレッドを協調的に mount / unmount する。

2.2 Pattern Matching for switch(確定)

`switch` がデータの形による真のディスパッチになる。

sealed interface Shape permits Circle, Rect, Triangle {}

record Circle(double r) implements Shape {}

record Rect(double w, double h) implements Shape {}

record Triangle(double b, double h) implements Shape {}

double area(Shape s) {

return switch (s) {

case Circle(double r) -> Math.PI * r * r;

case Rect(double w, double h) -> w * h;

case Triangle(double b, double h) -> 0.5 * b * h;

};

}

`sealed interface` + record deconstruction + 網羅性チェックがセットで入る。Scala / Kotlin / Rust の `match` に慣れた人にはほぼ同じ。`default` 不要な点が大きい。

2.3 Module Import Declarations(preview)

ファイル冒頭の `import java.util.*; import java.util.concurrent.*;` の山を 1 行に畳む。

void main() {

var client = HttpClient.newHttpClient();

var req = HttpRequest.newBuilder(URI.create("https://example.com")).build();

}

JEP 477(Implicit Classes / Instance Main)と合わせると、小さなスクリプトはほぼ Python 並みに短くなる。教育用途・jbang と相性が良い。

3. Project Loom — 仮想スレッド + 構造化並行性実戦

Loom の真の価値は、仮想スレッドと構造化並行性がセットで入ってきた点にある。

3.1 仮想スレッドの動作モデル

仮想スレッドは OS スレッドではなく、**JVM のヒープに住むオブジェクト**。JVM が carrier(= プラットフォームスレッド)上に mount し、I/O などのブロッキング地点で unmount し、別の仮想スレッドを mount する。含意は次のとおり。

- HTTP 呼び出し、JDBC、ファイル I/O はそのまま同期コードで書ける。`CompletableFuture` チェインや `Mono`/`Flux` の配管は不要。

- 「`synchronized` が carrier を pin する」歴史的問題は Java 24 の JEP 491 で解決。Java 25 LTS 以降は `synchronized` も概ね安全。

- 仮想スレッドは **絶対にプールしない**。プールこそアンチパターンで、タスクごとに新規作成する。

3.2 構造化並行性(JEP 480 / 505)

複数の並行タスクを親子関係で束ねる。子が失敗すれば兄弟も一緒にキャンセルされる。

record UserDashboard(User user, List<Order> orders, List<Notice> notices) {}

UserDashboard build(long userId) throws Exception {

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {

var userF = scope.fork(() -> userService.findById(userId));

var ordersF = scope.fork(() -> orderService.findByUser(userId));

var noticesF = scope.fork(() -> noticeService.findByUser(userId));

scope.join(); // 全部待つ

scope.throwIfFailed(); // どれか失敗したら伝播

return new UserDashboard(userF.get(), ordersF.get(), noticesF.get());

}

3 つのタスクが本当の意味で親のライフサイクルを共有する。親が割り込まれれば子も死に、スタックトレースにも親子関係が残る。実務では「1 リクエスト = 1 scope」が標準になる。

3.3 Scoped Values(JEP 506)

`ThreadLocal` を置き換える、仮想スレッド時代の安全で効率的なコンテキスト伝搬機構。

private static final ScopedValue<String> REQUEST_ID = ScopedValue.newInstance();

void handle(HttpRequest req) {

ScopedValue.where(REQUEST_ID, req.header("x-request-id"))

.run(() -> business());

}

void logInfo() {

log.info("request-id={}", REQUEST_ID.get());

}

`ThreadLocal` と違って (1) 不変、(2) scope 終了で自動解放、(3) 仮想スレッド間のコピーがほぼ無料。仮想スレッドを本格採用するなら、`ThreadLocal` は計画的に減らしていくのが筋。

4. Spring Boot 3.5 — Native + GraalVM 統合

Spring Boot 3.5(2025 年 5 月 GA)は **Java 17 最低、Java 21/25 推奨**、**Jakarta EE 11** ベース。要点。

4.1 仮想スレッドを 1 行で有効化

application.properties

spring.threads.virtual.enabled=true

この 1 行で Tomcat / Jetty / Undertow がリクエストハンドラを仮想スレッドで実行する。`@Async` の既定プールも仮想スレッドベースに切り替え可能。

@Configuration

class AsyncConfig implements AsyncConfigurer {

@Override public Executor getAsyncExecutor() {

return Executors.newVirtualThreadPerTaskExecutor();

}

HikariCP、Reactor Netty クライアント、外部 HTTP 呼び出しはそのまま使える。`synchronized` の多いライブラリに依存する場合は Java 25 推奨。

4.2 GraalVM Native Image が一級市民

Spring Boot + GraalVM native image

./mvnw -Pnative native:compile

あるいは cloud-native buildpack

./mvnw spring-boot:build-image -Pnative

- 起動時間は 50 〜 100 ms(JVM は通常 1 〜 3 秒)。

- メモリは JVM 比で 1/3 〜 1/5。

- 注意: AOT コンパイル時間は長く、reflection / proxy が多いライブラリはヒントが必要。

Spring Boot 3.5 は `@RegisterReflectionForBinding` などのヒント系アノテーションが安定し、Spring Data / Jackson / JPA の標準コードはヒント無しでもネイティブコンパイルが通る。

4.3 オブザーバビリティが一級市民

Micrometer + Tracing(Brave / OpenTelemetry)が既定の依存関係。OTel Java エージェントなしで `@Observed` 1 つで span が出る。

@Service

class OrderService {

@Observed(name = "order.create")

public Order create(OrderRequest req) { /* ... */ }

}

OTel collector へ出すには `management.otlp.tracing.endpoint` を 1 行足すだけ。

5. Quarkus 3.20 — Supersonic Subatomic Java

Quarkus(Red Hat)は **Kubernetes-native Java** を掲げる。差別化ポイント。

5.1 起動時間・メモリ優位

- JVM モード: 起動 1 〜 2 秒、RSS 100 〜 200 MB。

- Native モード(GraalVM): 起動 20 〜 30 ms、RSS 30 〜 50 MB。

この数字が Knative / Lambda / Cloud Run と相性が良い。scale-to-zero が意味を持つ。

5.2 開発体験 — Dev Mode + Continuous Testing

./mvnw quarkus:dev

- ファイル保存と同時にホットリロード。

- `r` を押すと変更されたファイルのテストだけ再実行(continuous testing)。

- 内蔵 Dev UI(`http://localhost:8080/q/dev/`)から拡張の設定、DB クエリ、REST endpoint の叩き込みまで可能。

5.3 コード例 — REST + Panache + Reactive

@Path("/users")

public class UserResource {

@GET @Path("/{id}")

public Uni<User> get(@PathParam("id") Long id) {

return User.<User>findById(id);

}

@POST

public Uni<Response> create(User user) {

return Panache.withTransaction(user::persist)

.replaceWith(Response.created(URI.create("/users/" + user.id)).build());

}

`Uni`/`Multi`(SmallRye Mutiny)が既定のリアクティブ型。ただし Quarkus 3.x からは Hibernate Reactive を使わず、ブロッキング + 仮想スレッドという組み合わせが一般化した。

5.4 拡張エコシステム

`quarkus-` 接頭辞の拡張が 600 個以上。Kafka、gRPC、Redis、Vault、Keycloak、Kubernetes config、OpenAPI、MicroProfile 全般 — ほぼ全部が一級で揃っている。

6. Micronaut 4 — Reactor 親和

Micronaut 4 の差別化は **コンパイル時 DI**。リフレクションではなくアノテーションプロセッサで Bean メタデータを生成するため、GraalVM ネイティブイメージとの相性が抜群。

@Controller("/hello")

public class HelloController {

@Get(uri = "/{name}", produces = MediaType.TEXT_PLAIN)

public String hello(String name) {

return "Hello, " + name;

}

- Project Reactor とすんなり噛み合う。Spring WebFlux からの移行も容易。

- GraalVM ネイティブイメージが既定シナリオ。コンパイル時間も Spring より短い。

- AWS Lambda / GCP Cloud Functions / Azure Functions のアダプタが一級。

トスやカカオでは Spring が圧倒的だが、コールドスタートが効く新規サービスで Micronaut を採用した例も出始めている。

7. Helidon 4 / Vert.x 5 — その他の選択肢

7.1 Helidon 4(Oracle)

Oracle 主導のマイクロサービスフレームワーク。**Helidon Nima** は最初から仮想スレッド前提で設計された新しいウェブエンジン(Netty 非依存)。

public class Main {

public static void main(String[] args) {

WebServer.builder()

.routing(r -> r.get("/hello", (req, res) -> res.send("Hello")))

.build()

.start();

}

Netty を介さず仮想スレッドを直接 carrier として使うため、並行モデルは最もシンプル。JVM メモリ使用量も非常に低い。Oracle Cloud との相性が良い。

7.2 Vert.x 5

イベントループベースのリアクティブツールキット。1 ノードで非常に高い同時接続数をさばきたい場合に強い。

Vertx vertx = Vertx.vertx();

vertx.createHttpServer()

.requestHandler(req -> req.response().end("Hello"))

.listen(8080);

Vert.x 5 はリアクティブと共に仮想スレッドモードもサポートし、コールバック地獄を回避できる。メッセージゲートウェイ、IoT ゲートウェイ、WebSocket サーバなど、接続数が爆発するワークロードの常連。

8. ZGC — sub-ms pause GC

Java 25 LTS 時点で **Generational ZGC がデフォルト GC** になった。

8.1 なぜ重要か

G1 GC が数十〜数百 ms の stop-the-world pause を出しうるのに対し、ZGC は **GC pause を 1 ms 未満**に保つ。ヒープ規模が数 GB でも数百 GB でも同じ pause 特性。

8.2 有効化

java -XX:+UseZGC -Xmx16g -jar app.jar

Java 21 では `-XX:+ZGenerational` で generational モードを明示的に有効化していたが、Java 25 LTS ではそれがデフォルトになった。

8.3 トレードオフ

- スループットは G1 比で若干低い(通常 5 〜 10 %)。

- メモリフットプリントは G1 より大きい(color pointer オーバーヘッド)。

- 真価が出るのは **p99 レイテンシが KPI** のワークロード — 決済、トレーディング、広告入札。

トスの決済ゲートウェイやメルカリの注文処理のように p99 が SLA の場合、ZGC は事実上の標準。

9. Project Valhalla — value types

Valhalla はまだ「もうすぐ」の領域だが、2026 年時点で **value types(JEP 401 / 402)** が preview まで来ている。

9.1 何が変わるか

value class Point {

int x;

int y;

}

- `Point` は **identity を持たない**オブジェクト。すなわち `==` が値比較。

- JVM が **flatten** して配列内にインライン配置できる。`Point[]` が本当の意味で連続メモリになる。

- ボクシングコストが消える。`int` 並みに動くがクラスインターフェースを持つ。

9.2 なぜ重要か

これまで Java のオブジェクトは必ずヒープ上のポインタ経由だった。数値計算、ML テンソル、ゲームエンジンのように「数十万の小さなオブジェクト」を扱うワークロードでは、ボクシングとキャッシュミスのコストが C++ / Rust 比で大きかった。Valhalla が GA すれば、その差はかなり縮まる。2026 年時点で本番採用は時期尚早だが、DJL などのライブラリは既に準備中。

10. Project Panama(FFI、Java 22 GA)— jextract と一緒に

Panama の Foreign Function & Memory API(FFM)は Java 22 で GA。JNI の後継、そしてはるかに安全な代替。

10.1 基本 — C 関数の呼び出し

try (Arena arena = Arena.ofConfined()) {

Linker linker = Linker.nativeLinker();

SymbolLookup stdlib = linker.defaultLookup();

MethodHandle strlen = linker.downcallHandle(

stdlib.find("strlen").orElseThrow(),

FunctionDescriptor.of(JAVA_LONG, ADDRESS)

);

MemorySegment cString = arena.allocateUtf8String("Hello, Panama!");

long len = (long) strlen.invoke(cString);

System.out.println(len); // 14

}

JNI と比べた利点。

- `Arena` がメモリのライフサイクルを管理するため、リークがほぼ起きない。

- 安全な off-heap メモリアクセス(bounds-check 付き)。

- jextract による自動生成バインディングで boilerplate がほぼゼロ。

10.2 jextract — C ヘッダから Java バインディング自動生成

例: SQLite の C ヘッダから Java バインディングを生成

jextract --source --output gen \

-t org.sqlite.ffi \

/usr/include/sqlite3.h

`org.sqlite.ffi.sqlite3_h` のようなクラスが生成され、`sqlite3_open` / `sqlite3_exec` が Java の `MethodHandle` として露出する。結果として、JNI を 1 行も書かずにネイティブライブラリを使える。

10.3 採用領域

- 高性能圧縮(zstd、snappy)ライブラリ。

- 機械学習推論(ONNX Runtime、llama.cpp)の統合。

- ハードウェアアクセラレーション(CUDA、Apple Metal)呼び出し。

- メモリマップトファイルを直接処理する OLAP エンジン(Apache Arrow など)。

JNI 時代は「性能のために仕方なく」だったのが、Panama 時代には「既定の選択肢」になった。

11. Project Babylon — JVM の GPU/AI コンピュート

Babylon(2024 〜)は OpenJDK の新プロジェクト。**Code Reflection** という機能を通じて Java コードを別のプログラミングモデル(GPU、SQL、微分可能関数など)に変換できるようにする。

11.1 動機

これまで Java から GPU を使うには (1) JNI で CUDA 呼び出し、(2) ONNX Runtime や TornadoVM などの外部ツール経由、しか無かった。Babylon の狙いは、**純粋な Java コードをそのまま GPU カーネルへコンパイル**できる標準 API を提供すること。

11.2 概念図

Java source Reflected method body (IR) Target backend

@CodeReflection ────► Op tree (SSA) ────► SPIR-V / PTX / SQL / ...

void matmul(...) { }

Babylon はライブラリ作者が **自分の専用アノテーション + IR コンシューマ**を実装するためのインフラ。TornadoVM や HAT(Heterogeneous Accelerator Toolkit)が Babylon の上で動く形。

11.3 2026 年における意味

Java は AI/ML の「サービス層」言語としての地位を固めたが、「学習・推論層」では常に Python に劣勢だった。Babylon が安定すれば、Java で直接 GPU カーネルを書けるようになり、推論サービスの一部をネイティブ化する道が開ける。まだ incubating だが、方向性は正しい。

12. GraalVM 25 — native image

GraalVM 25(2025 年 9 月)は OpenJDK 25 と一緒にリリースされた。2 本柱。

12.1 Native Image

Spring Boot / Quarkus / Micronaut いずれでも

native-image --no-fallback -jar app.jar

- 起動: 20 〜 100 ms。

- メモリ: JVM 比で 1/3 〜 1/5。

- トレードオフ: ビルド時間が長い(数分)、reflection / proxy / リソースロードを明示する必要あり。

Spring Boot 3.5 + GraalVM 25 の組み合わせは reachability metadata が自動収集されるため、ほとんどの標準 Spring コードはヒント無しでネイティブ化される。

12.2 Polyglot

GraalVM 上では JavaScript / Python / Ruby / Wasm / R / LLVM bitcode が同居して動く。Java 関数から JS 関数をそのまま呼べる:

try (Context ctx = Context.create("js")) {

Value array = ctx.eval("js", "[1,2,3]");

System.out.println(array.getArraySize()); // 3

}

実務では polyglot より native image のほうがはるかに頻繁に使われる。

12.3 Oracle GraalVM vs GraalVM CE

Java 21 以降、Oracle GraalVM は GFTC ライセンス(本番無償、ファストパスコンパイラ込み)で公開された。CE / EE の区別が事実上消え、**本番でも無償**で使える。

13. Maven 4 + Gradle 9 + jbang

13.1 Maven 4

Maven にとって 10 年ぶりのメジャーアップグレード。主な変更点。

- `pom.xml` の consumer / build POM 分離 — 公開される POM がきれいになる。

- マルチモジュールビルドの依存関係自動推論。

- ビルドキャッシュ・並列ビルドの強化。

- `mvnup` / `mvnsh` などの新しいツール。

既存の `pom.xml` はほぼそのまま動くので、移行コストは低い。

13.2 Gradle 9

- Configuration Cache が安定 — `gradle build` がキャッシュヒット時にほぼ瞬時に起動。

- Kotlin DSL が推奨。Groovy DSL も引き続きサポートされるが、新規プロジェクトは Kotlin DSL 推奨。

- ビルドオーサリングのガイド(`buildSrc` → version catalog)が標準化。

plugins {

id("org.springframework.boot") version "3.5.0"

id("io.spring.dependency-management") version "1.1.6"

kotlin("jvm") version "2.1.0"

}

dependencies {

implementation("org.springframework.boot:spring-boot-starter-web")

implementation("org.springframework.boot:spring-boot-starter-data-jpa")

runtimeOnly("org.postgresql:postgresql")

}

13.3 jbang — Java をスクリプトに

単一ファイルで Spring Boot アプリを動かす

jbang hello.java

///usr/bin/env jbang "$0" "$@" ; exit $?

//DEPS info.picocli:picocli:4.7.6

@Command(name = "hello")

public class hello implements Runnable {

public void run() { System.out.println("Hello from jbang!"); }

public static void main(String[] args) { new CommandLine(new hello()).execute(args); }

}

`//DEPS` コメントで依存を宣言すると Maven の resolver が解決する。CLI ツール、CI 自動化スクリプト、アドホックなデータ処理に便利。Java 25 の Implicit Classes(JEP 477)と組み合わせるとほぼ Python 並みに短い。

14. 韓国 / 日本 — トス、カカオペイ、メルカリ、LINE、NTT データ、楽天

14.1 韓国

- **トス(Toss)** — コア決済・送金システムは今も **Java + Spring Boot** が大半。一部の新規サービスは Kotlin / Spring。2024 年から仮想スレッド導入の発表が増えてきた。ZGC も決済ゲートウェイの標準 GC。

- **カカオペイ** — Java + Spring Boot が中心。Kafka ベースのイベント駆動アーキテクチャ。リアクティブと並行して仮想スレッドを段階導入中。

- **NAVER / LINE** — 多くのサービスが Java / Kotlin / Spring。LINE Pay は韓国・日本・台湾のマルチリージョン構成。

- **クーパン** — Java + Spring + Kafka が中心。新規サービスでは Kotlin の比率が増加。

14.2 日本

- **メルカリ(Mercari)** — 検索・推薦周りは Go / Python だが、商品・決済・精算は Java / Kotlin。JVM 運用ノウハウ(GC チューニング、ZGC)の発信で知られる。

- **LINE ヤフー** — Java + Kotlin + Spring の大規模事例。Vert.x ベースのメッセージゲートウェイも一部運用。

- **NTT データ** — エンタープライズ SI の標準。ミッションクリティカル系で Java 17/21 LTS が定着。Spring Boot と合わせて Helidon / Quarkus も採用。

- **楽天(Rakuten)** — グローバル EC プラットフォームは Java + Spring が中心。楽天モバイルではリアクティブと共に Vert.x も活用。

- **デンソー / ソニー / 日立** — 組込み・IoT ゲートウェイで Helidon Nima が採用されつつある。

共通パターンは「Java / Kotlin / Spring モノリス + Kafka イベント駆動 + 新規サービスに仮想スレッド / ネイティブイメージ」。

15. 誰が Java / Spring を選ぶべきか — エンタープライズ / 金融 / モノリス / 多言語チーム

15.1 強く推奨

- **エンタープライズ / 金融 / 通信** — 規制、監査証跡、長期保守が肝。Java 25 LTS の 8 年サポート、Spring のエコシステム、Quarkus の運用ツールは他言語が真似しにくい。

- **モノリスから始める新規サービス** — Spring Boot の「convention over configuration」が圧倒的に速く価値を出せる。モジュール分割は後で。

- **JVM ライブラリ資産が大きいチーム** — Kafka、Hadoop、Spark、Flink、Cassandra、Elasticsearch — データインフラのほぼ全てが JVM。同じ言語で運用・統合・デバッグできる。

15.2 条件付き推奨

- **コールドスタートが要のサーバレス** — Quarkus + GraalVM、あるいは Micronaut + GraalVM。Java / Spring の一般的構成はコールドスタートが弱い。

- **接続数爆発(IoT、WebSocket、ゲームサーバ)** — Vert.x や Helidon Nima のほうが適合する。

- **データサイエンス / ML 学習パイプライン** — Python が依然優勢。Java はサービス層 / 推論ゲートウェイ。

15.3 非推奨

- **CLI 単一バイナリツール** — Go / Rust が自然。(ただし jbang + GraalVM は意外と競争力あり。)

- **システムプログラミング** — Rust / C++ / Zig。

15.4 Java vs Kotlin

同じ JVM だが選択基準は異なる。Java は「組織標準が Java」あるいは「ライブラリが Java 中心」のとき、Kotlin は「DSL の多いドメイン」や「Android とコード共有」のとき。Spring は Kotlin も一級でサポートするため、新規サービスで Kotlin を採用する韓国・日本企業が急増している。

参考 / References

- [OpenJDK — Java 25 LTS](https://openjdk.org/projects/jdk/25/)

- [JEP Index](https://openjdk.org/jeps/0)

- [JEP 444 — Virtual Threads (Java 21)](https://openjdk.org/jeps/444)

- [JEP 480 / 505 — Structured Concurrency](https://openjdk.org/jeps/505)

- [JEP 506 — Scoped Values](https://openjdk.org/jeps/506)

- [JEP 491 — Synchronize Virtual Threads without Pinning](https://openjdk.org/jeps/491)

- [JEP 441 — Pattern Matching for switch](https://openjdk.org/jeps/441)

- [JEP 511 — Module Import Declarations](https://openjdk.org/jeps/511)

- [JEP 454 — Foreign Function & Memory API (Java 22 GA)](https://openjdk.org/jeps/454)

- [Project Loom](https://openjdk.org/projects/loom/)

- [Project Valhalla](https://openjdk.org/projects/valhalla/)

- [Project Panama](https://openjdk.org/projects/panama/)

- [Project Babylon](https://openjdk.org/projects/babylon/)

- [Spring Boot 3.5 Release Notes](https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.5-Release-Notes)

- [Quarkus](https://quarkus.io/)

- [Micronaut](https://micronaut.io/)

- [Helidon](https://helidon.io/)

- [Vert.x](https://vertx.io/)

- [GraalVM](https://www.graalvm.org/)

- [Maven 4](https://maven.apache.org/docs/4.0.0/release-notes.html)

- [Gradle 9](https://docs.gradle.org/current/release-notes.html)

- [jbang](https://www.jbang.dev/)

- [jextract](https://github.com/openjdk/jextract)

- [Mercari Engineering Blog](https://engineering.mercari.com/en/blog/)

- [LINE Engineering Blog](https://engineering.linecorp.com/en/blog/)