モダン Java 2026 — Java 25 LTS / Spring Boot 3.5 / Quarkus / 仮想スレッド / GraalVM 25 / Loom / Panama 徹底ガイド

モダン 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 行に畳む。

import module java.base;
import module java.net.http;

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)

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

import jdk.incubator.concurrent.StructuredTaskScope;

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 関数の呼び出し

import java.lang.foreign.*;
import static java.lang.foreign.ValueLayout.*;

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

import picocli.CommandLine;
import picocli.CommandLine.Command;

@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 を採用する韓国・日本企業が急増している。