JExten：基于Java模块系统（JPMS）构建健壮的插件架构

1. 动机：通往模块化隔离之路

在Java中构建可扩展应用程序时，开发者常常从一个简单的问题开始："如何让用户无需重新编译核心应用程序就能添加功能？" 旅程通常始于标准的 java.util.ServiceLoader，它提供了一种发现接口实现的简单机制。

然而，随着应用程序的增长，一个关键问题出现了："类路径地狱"。

想象一下，你有一个使用 library-v1 的主机应用程序。你创建了一个插件系统，有人写了一个需要 library-v2 的 "Twitter 插件"。如果所有东西都在同一个扁平的类路径上运行，就会产生冲突。要么主机因为得到错误的库版本而崩溃，要么插件失败。你无法在类路径上同时存在同一个库的两个版本而不面临运行时异常（如 ClassDefNotFoundError 或 NoSuchMethodError）的风险。

这正是JExten背后的核心驱动力。我需要一种能够严格封装插件的方式，使得每个插件都可以定义自己的依赖，而不影响主机或其他插件。

引入JPMS（Java平台模块系统）

Java 9引入了模块系统（JPMS），它提供了强封装和显式的依赖关系图。它允许我们创建隔离的模块"层"。

• 启动层：JVM和平台模块。
• 主机层：核心应用程序及其依赖。
• 插件层：在主机层之上动态创建的层。

通过利用JPMS的ModuleLayers，JExten允许插件A依赖于Jackson 2.14，而插件B依赖于Jackson 2.10，两者可以在同一个运行的应用程序中和睦共存。

2. 架构与设计

JExten设计为轻量级且基于注解驱动，抽象了原始ModuleLayers的复杂性，同时提供了依赖注入（DI）和生命周期管理等强大功能。

架构基于三个主要支柱：

扩展模型

核心在于，JExten在"契约"（API）和"实现"之间进行了清晰分离。

• 1. 扩展点 (@ExtensionPoint)：在主机应用程序（或共享API模块）中定义的接口，规定了哪些功能可以被扩展。

     @ExtensionPoint(version = "1.0")
     public interface PaymentGateway {
     void process(double amount);
     }

• 2. 扩展 (@Extension)：由插件提供的具体实现。

     @Extension(priority = Priority.HIGH)
     public class StripeGateway implements PaymentGateway {
     // ...
     }

     注意，你可以在没有PluginManager的情况下使用ExtensionManager。这在测试中或当你希望在非插件环境中使用JExten，且所有扩展都已经在模块路径中可用时非常有用。

管理器分离

为了分离关注点，该库将职责划分到两个不同的管理器：

• 1. PluginManager（"物理层"）：
     • 该组件处理原始工件（JAR/ZIP文件）。
     • 它使用SHA-256校验和验证完整性，确保插件未被篡改。
     • 它构建JPMS ModuleLayer 图。它读取 plugin.yaml 清单，解析依赖项（从本地缓存或Maven仓库），并构建类加载环境。
• 2. ExtensionManager（"逻辑层"）：
     • 一旦层构建完成，该组件接管。
     • 它在各个层中扫描带有 @Extension 注解的类。
     • 它管理这些扩展的生命周期（单例、会话或原型作用域）。
     • 它处理依赖注入。

依赖注入

由于插件在隔离的层中运行，标准的DI框架（如Spring或Guice）有时可能"太重"或在动态模块边界间配置起来很棘手。JExten包含一个内置的、轻量级的DI系统。

你可以简单地使用 @Inject 将扩展连接在一起：

@Extension
public class MyPluginService {
    @Inject
    private PaymentGateway gateway; // 自动注入最高优先级的实现
}

这在模块边界之间可以无缝工作。一个插件可以注入由主机提供的服务，甚至可以注入由另一个插件提供的服务（如果模块关系图允许的话）。

3. 使用示例

下面快速了解一下如何定义扩展点，在插件中实现它，并在应用程序中使用。

I. 定义一个扩展点

创建一个接口并用 @ExtensionPoint 注解。这是插件将实现的契约。

@ExtensionPoint(version = "1.0")
public interface Greeter {
    void greet(String name);
}

II. 实现一个扩展

在你的插件模块中，实现该接口并用 @Extension 注解。

@Extension
public class FriendlyGreeter implements Greeter {
    @Override
    public void greet(String name) {
        System.out.println("Hello, " + name + "!");
    }
}

III. 发现与使用

在你的主机应用程序中，使用 ExtensionManager 来发现和调用扩展。

public class Main {
    public static void main(String[] args) {
        // 初始化管理器
        ExtensionManager manager = ExtensionManager.create(pluginManager);

        // 获取Greeter扩展点的所有扩展
        manager.getExtensions(Greeter.class)
               .forEach(greeter -> greeter.greet("World"));
    }
}

IV. 将你的扩展打包为插件

最后，使用 jexten-maven-plugin Maven插件在编译时检查你的 module-info.java，并将你的扩展打包成一个包含所有依赖项和生成的 plugin.yaml 清单的ZIP包。

<plugin>
    <groupId>org.myjtools.jexten</groupId>
    <artifactId>jexten-maven-plugin</artifactId>
    <version>1.0.0</version>
    <executions>
        <execution>
            <goals>
                <goal>generate-manifest</goal>
                <goal>assemble-bundle</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <hostModule>com.example.app</hostModule>
    </configuration>
</plugin>

然后，你可以将生成的ZIP包安装到你的主机应用程序中：

public class Application {
    public static void main(String[] args) throws IOException {
        Path pluginDir = Path.of("plugins");

        // 创建插件管理器
        PluginManager pluginManager = new PluginManager(
            "org.myjtools.jexten.example.app", // 应用程序ID
            Application.class.getClassLoader(),
            pluginDir
        );

        // 从ZIP包安装插件
        pluginManager.installPluginFromBundle(
            pluginDir.resolve("my-plugin-1.0.0.zip")
        );

        // 创建支持插件的扩展管理器
        ExtensionManager extensionManager = ExtensionManager.create(pluginManager);

         // 从插件获取扩展
        extensionManager.getExtensions(Greeter.class)
            .forEach(greeter -> greeter.greet("World"));
    }
}

4. 与其他解决方案的比较

选择合适的插件框架取决于你的具体需求。以下是JExten与一些成熟替代方案的对比：

PF4J (Plugin Framework for Java)

PF4J是一个成熟的、轻量级的插件框架，依赖于ClassLoader隔离。

• 隔离性：PF4J使用自定义ClassLoader隔离插件。JExten使用JPMS ModuleLayers。后者是自Java 9以来处理隔离的"原生"Java方式，在JVM级别严格执行封装。
• 现代性：虽然PF4J非常优秀，但JExten是专门为现代模块化Java生态系统（Java 21+）设计的，利用模块描述符（module-info.java）来定义依赖关系，而不是自定义清单。

OSGi

OSGi是模块化的黄金标准，为Eclipse等IDE提供支持。

• 复杂性：OSGi功能强大，但学习曲线陡峭且样板代码多（Manifest头、Activators、复杂的服务动态）。JExten通过专注于80%的用例——具有简单依赖注入的严格隔离扩展——提供了远低于OSGi的复杂性（"精简版OSGi"），且不需要完整的OSGi容器。
• 运行时：OSGi带来沉重的运行时。JExten是一个轻量级库，构建在标准JVM特性之上。

Layrry

Layrry是一个用于执行模块化Java应用程序的启动器和API。

• 关注点：Layrry非常侧重于模块层的配置和组装（通常通过YAML/TOML），并充当运行器。JExten则侧重于这些层内的编程模型。
• 特性：Layrry擅长构建层，但它不提供固化的应用框架。JExten提供了"粘合"代码——扩展点、依赖注入和生命周期管理——这些是你在使用原始模块层或Layrry时必须自己编写的东西。

5. 结论

JExten是一个轻量级、基于注解驱动的插件框架，它利用JPMS模块层来提供隔离和依赖管理。其设计目标是易于使用和理解，注重简洁性和易用性。

最后，请记住JExten仍处于早期阶段，有很大的改进空间。欢迎在GitHub上为项目做贡献和/或在issue部分参与讨论。项目仓库链接在此处。

【注】本文译自：JExten: Building a Robust Plugin Architecture with Java Modules (JPMS) – DEV Community

Java 中的 JSON 处理很少是简单的。

在实际应用中，数据不断在以下形式之间流转：

• POJO（普通Java对象）
• Map / List
• JSON 字符串
• 配置文件
• 模式不断演进的 API

Java 开发者常常被迫做出痛苦的选择：

要么要类型安全，要么要灵活性——二者不可兼得。

SJF4J（Java 简单 JSON 门面） 就是为了消除这种取舍而构建的。

SJF4J 是什么？

SJF4J 是流行 JSON 库（Jackson、Gson、Fastjson2）及相关格式（YAML、Properties）之上的一个轻量级门面。它提供一个用于结构化数据处理的统一语义层，完全基于 JSON 规范。它不替代你的 JSON 解析器，而是在它们之上统一你的结构化数据处理方式。

核心理念：基于对象的节点树

SJF4J 没有引入自定义的 JSON AST（抽象语法树），而是将现有的 Java 对象视为 JSON 节点。这被称为基于对象的节点树[Object-Based Node Tree (OBNT)]。

在 OBNT 中：

• JSON 对象 → JsonObject、Map、POJO
• JSON 数组 → JsonArray、List、数组
• JSON 值 → Java 原生类型

一切都保持为普通的 Java 对象，只是在上层附加了 JSON 语义。

快速示例

JsonObject jo = JsonObject.fromJson("""
{
  "id": 1,
  "active": true
}
""");

int id = jo.getInt("id");              // 类型安全
String active = jo.asString("active"); // Boolean → String 转换

SJF4J 提供三种访问级别：

• getNode → 原始访问
• getXxx → 类型安全访问
• asXxx → 语义访问，支持跨类型转换

你可以为每次调用选择严格程度。

基于路径的访问（符合 RFC 规范）

SJF4J 完全支持：

• JSON 路径（RFC 9535）
• JSON 指针（RFC 6901）

String name = jo.asByPath("$.user.name");
List<Integer> ids = jo.findByPath("$.items[*].id", Integer.class);

同样的路径 API 适用于：

• JSON
• Map / List
• POJO
• 混合对象图

动态 + 类型化：JOJO

SJF4J 引入了 JOJO（JSON 对象 Java 对象）—— 一个扩展了 JsonObject 的领域对象。

class User extends JsonObject {
    String name;
}
user.getName();               // 类型化访问
user.getString("age");        // 动态访问
user.findByPath("$..name");   // JSON 语义访问

你可以从动态访问开始，逐步添加结构 —— 而无需破坏 API。

使用 JsonPatch 进行声明式转换

SJF4J 支持：

• JSON 补丁（RFC 6902）
• JSON 合并补丁（RFC 7386）

JsonPatch patch = JsonPatch.diff(source, target);
patch.apply(source);

补丁操作在 POJO、Map、List 和 JSON 对象上统一工作。

SJF4J 何时大放异彩？

如果你符合以下情况，SJF4J 是理想选择：

• 处理不断演进或半结构化的数据
• 既需要灵活性又需要类型安全
• 希望在多个 JSON 库上使用统一的 API
• 关注 JSON 规范

总结

SJF4J 让面向 JSON 的 Java 开发成为可能 —— 无需过早锁定方案或编写过多样板代码。

它小巧、可组合，并且由规范驱动。

👉 GitHub: https://github.com/sjf4j-projects/sjf4j

【注】本文译自：SJF4J in 5 Minutes: A Practical JSON Facade for Java

1. 引言：Java的演进轨迹

随着2026年的临近，Java正处于一个引人入胜的转折点。该平台并非仅仅维持其地位，而是通过Valhalla、Panama、Amber和Vector API等项目经历着重大创新。这些举措不仅仅代表渐进式改进，它们从根本上重塑了Java处理数据、与本机代码互操作以及表达开发者意图的方式。

自Java 9引入的六个月发布节奏在保持稳定性的同时加速了创新。Java 21在发布数月内采用率已达到45%，这表明当新功能带来切实价值时，社区乐于接受。本文将探讨Java即将到来的最重要增强功能的理论基础、架构原理和战略意义。

2. Project Valhalla：重新思考对象模型

2.1 Java必须解决的内存问题

自1995年以来优雅而简单的Java对象模型，如今与现代硬件的现实严重不匹配。Java诞生之初，内存读取操作和算术运算的成本大致相当，但如今内存读取的成本比算术运算高出200到1000倍。硬件经济的这一根本性转变使得Java大量使用指针的数据表示方法问题日益突出。

以坐标或颜色值这类简单的数据结构为例。传统Java即使是针对最小的数据载体，也会创建具有身份标识和开销的完整堆对象。这种间接引用级联——对象数组包含指向分散堆位置的引用——破坏了缓存局部性，并迫使进行昂贵的内存遍历。

2.2 值类型：像类一样编码，像int一样工作

Project Valhalla引入了值类，它将面向对象的抽象与原始类型的性能特性相结合，允许存在没有身份标识且可以优化编码的对象。其概念性突破在于认识到并非所有对象都需要身份标识。许多数据结构——坐标、复数、元组——代表的是纯粹的值而非实体。

值类牺牲了依赖于身份标识的特性（通过==进行的引用相等性、同步），以换取显著的内存和性能改进。值类仍然支持null，因为它们是引用类型；而受到更严格约束的原始类则完全放弃了null支持，但允许进行更激进的优化。

2.3 架构影响

其影响远不止于单个对象。2025年10月的早期访问基准测试显示，在从一个包含5000万个LocalDate实例的数组中求和年份时，性能提升近3倍，相较于基于身份标识的对象，平均执行时间从约72毫秒减少到25毫秒。

这种性能增益源于扁平化——将值对象数据直接嵌入数组和字段，而不是存储引用。这样得到的是一个连续的实际数据块，而非包含指向分散堆对象指针的数组，完美适配现代CPU缓存架构。

2.4 增强泛型与具体化

Valhalla的范围还包括解决Java长期存在的泛型类型擦除限制。增强泛型旨在实现对对象引用、原始类型、值类型以及可能void的泛型支持，从而消除对装箱变通方案的需求。这意味着List<int>成为可能，无需包装对象，既消除了内存开销，也减轻了分配压力。

2.5 时间线与现状

截至2025年10月，JEP 401：值类与对象已提供早期访问构建版本，在JDK 26的早期访问构建中实现了具有预览功能的值类。预计将通过持续不断的增强功能在多个版本中交付，而非一次性的庞大更新。现实的稳定目标指向Java 26-27（2026-2027）达到生产就绪状态。

3. Project Panama：连接Java与本机代码

3.1 JNI问题陈述

几十年来，Java本地接口一直作为Java访问本地库的网关，但其复杂性带来了巨大成本。JNI要求同时具备Java和本地编程的专业知识，通常导致编写容易出错的胶水代码、频繁跨越边界带来的性能开销、手动内存管理带来的泄漏或崩溃风险，以及直接内存访问引发的安全问题。

3.2 外部函数与内存API架构

Project Panama的外部函数和内存API经过自Java 14以来的孵化，在Java 22中成为标准，为开发者提供了调用本地函数、分配本地内存和映射本地数据结构的直接方式。其架构优雅之处在于实现了类型安全的内存访问，同时不牺牲性能。

该API引入了几个关键抽象：

• 内存段：对内存源（堆内或堆外）的有限、有时限、线程受限的视图。与原始指针不同，内存段携带大小信息和生命周期管理。
• 链接器：JVM与C/C++本地代码之间的桥梁，为Win64、SysVx64、LinuxAArch64和MacOsAArch64提供了平台特定的实现。
• 函数描述符：本地函数签名的类型安全规范，确保Java与本地约定之间正确的数据编排。
• 基于竞技场的内存管理：作用域分配，自动释放资源，防止困扰手动JNI代码的内存泄漏。

3.3 性能与安全特性

安全性与原始性能之间的权衡值得审视。虽然互操作代码是用Java编写的，但不能认为是100%安全的，因为运行时必须信任开发者对本地函数的描述，这也是访问外部链接器是一项受限操作、需要foreign.restricted=permit标志的原因。

这种设计有意暴露了本地互操作的内在风险，同时为防止常见错误提供了护栏。该API通过编译时和运行时检查防止了许多类型的错误——缓冲区溢出、释放后使用、空指针解引用——但也承认本地代码边界代表着信任边界。

3.4 生产状态

截至2025年，FFM API经过自Java 19以来的严格改进，被认为是基本稳定的，具有简化的内存管理、增强的安全措施和定制功能。在Java 22中从预览版过渡到生产版标志着一个重要的里程碑，使Panama成为新开发中JNI的现代替代品。

4. Project Amber：表达能力的演进

4.1 减少仪式感理念

Project Amber的使命是通过一个常被称为“语言仪式感适度化”的过程，识别并孵化较小的、以提高生产力为导向的语言特性，使日常Java代码更易读、易写、易维护。与针对性能或互操作性的项目不同，Amber侧重于开发者的易用性和表达力。

4.2 已完成的功能

已交付的功能从根本上改变了现代Java代码的外观和感觉：

• 局部变量类型推断：在编译器可以推断类型的地方消除冗余的类型声明，在不牺牲类型安全的前提下减少代码噪音。
• Switch表达式：将switch从语句转变为具有详尽性检查和模式匹配能力的表达式，实现了简洁、安全的条件逻辑。
• 文本块：尊重格式的多行字符串字面量，消除了为SQL、JSON和HTML进行的字符串拼接技巧。
• 记录类：用于不可变数据载体的紧凑语法，自动派生equals、hashCode和toString实现。
• 密封类：通过明确许可哪些类型可以扩展或实现一个密封类型，来控制继承层次结构，从而支持详尽的模式匹配。
• 模式匹配：增强的instanceof和switch以支持模式匹配，消除了类型检查后的显式强制转换，并支持复杂的数据解构。

4.3 当前演进中的功能

对于2025年，Amber专注于敲定四个预览功能：允许在super/this调用之前执行代码的灵活构造函数体、简化入口点的紧凑源文件和实例主方法、用于简洁包导入的模块导入声明，以及用于原始类型匹配的原始模式。

除此之外，探索性工作仍在继续：

• 自定义解构器：将模式匹配扩展到记录类之外的任意类，允许在不要求记录类约束的情况下进行解构。
• Withers：一种with表达式，将实例解构为变量，允许重新分配其值，然后调用构造函数生成修改后的副本。
• 字符串模板：安全、高效的字符串插值机制，该功能在Java 23中为重新设计而移除，但仍在积极开发中。

4.4 面向数据的编程范式

Amber的开发努力与面向数据编程范式紧密契合，侧重于使数据不可变、将数据与行为分离，以及设计具有清晰、可预测结构的数据聚合。这代表了对传统面向对象编程的补充方法，而非替代，为那些透明数据建模比封装更有优势的场景提供了工具。

5. Vector API：显式SIMD编程

5.1 自动向量化的局限性

现代CPU提供SIMD能力，可以同时对多个数据元素执行操作。如今，编写本应向量化的标量操作的开发者需要了解HotSpot的自动向量化算法及其局限性，才能获得可靠的性能，并且在某些情况下可能无法编写可转换的标量操作。

这种对编译器启发式方法的依赖使得性能不可预测。看似语义相同的简单更改可能会阻止向量化，让开发者没有可靠的方式来表达可向量化的意图。

5.2 Vector API设计原则

Vector API提供了直接在Java中执行SIMD操作的向量类型、操作和工厂，具有清晰简洁的API，能够表达广泛的向量计算，且对向量大小通用，从而能在支持不同向量大小的硬件上实现可移植性。

其架构方法优先考虑：

• 平台无关性：使用Vector API编写的代码可在x64、ARM和RISC-V平台上运行，并进行适当的专门化。
• 可预测的编译：在具有能力的x64架构上，HotSpot C2应该将向量操作编译为相应的高效向量指令，开发者确信所表达的操作与相关向量指令紧密对应。
• 优雅降级：当向量计算无法完全表达为向量指令时（可能是因为架构不支持所需的指令），实现会优雅降级且仍能运行。

5.3 性能特征

基准测试显示，在两个大整数数组求和的简化案例中，使用Vector API相比标量操作实现了超过4倍的性能提升。实际收益很大程度上取决于数据访问模式、缓存行为以及所涉及的具体操作。

性能方面包含重要注意事项。主内存访问每次访问成本为60-100+个CPU周期，因此随着数组大小超过CPU缓存容量，更多的内存访问会降低Vector API的优势。此外，JIT自动向量化有时能对简单模式达到类似效果，使得该API对于破坏自动向量化的复杂算法最有价值。

5.4 与Panama和Valhalla的集成

Vector API在x64上利用Intel短向量数学库，在ARM和RISC-V上利用SIMD初等函数求值库，使用Panama的外部函数和内存API链接到本地数学函数。此外，Vector API使用装箱类型作为原始类型的代理，这是受当前泛型限制所迫，预计在Valhalla引入能力更强的泛型后会有所改变。

5.5 现状与时间线

JEP 529：Vector API（第十一次孵化）目标定于2025年12月的JDK 26，表明在最终确定之前将继续完善。延长的孵化期反映了在保持API稳定性的同时，在多样化的硬件平台上实现一致性能的复杂性。现实的稳定目标可能随Java 26（2026）一起到来。

6. 模块系统：采用与现实

6.1 JPMS概念基础

Java平台模块系统是一种代码级结构，它不改变JAR打包方式，但通过module-info.java文件添加了更高层级的描述符，使开发者更容易组织大型应用程序和库，同时改进了平台结构和安全性。

模块系统解决了几个架构问题：

• 类路径地狱：类路径最终变成了一个庞大无差别的大桶，所有依赖项都插入其中，模块路径在其上增加了一个层级，作为包的存储，并选择哪些包是可访问的。
• 封装性：模块显式声明它们导出哪些包以及需要哪些其他模块，防止意外依赖内部API。
• 显式依赖：模块依赖关系的编译时验证减少了运行时意外，并便于进行静态分析。

6.2 采用模式与挑战

截至2025年，JPMS在GraalVM本地镜像编译中的使用有所增长，其中模块化应用程序通过排除未使用的代码路径实现提前优化，从而产生适用于无服务器和边缘场景的紧凑可执行文件。

然而，企业采用呈现出审慎的速度。Spring Boot在JPMS集成方面已取得进展，在版本3中提供对模块化JAR的部分支持，并在Spring Boot 4中实现了自动配置的完全模块化，将大型构件拆分为有针对性的模块，以最小化类路径污染。

逐步采用反映了实际约束。许多组织维护着大量的遗留代码库，其中模块化意味着大量的重构投入。自动模块机制——为非模块化JAR提供隐式模块描述符——提供了迁移路径，但并未带来全部好处。

6.3 强封装的演进

从Java 16开始，强封装成为默认设置，除非通过标志明确允许，否则将非法访问转为错误，Java 17使–illegal-access选项过时并强制执行严格封装。这一进程平衡了迁移兼容性与安全目标。

强制执行时间线展示了Java的理念：提供警告和迁移路径，然后在社区适应后加强保证。依赖内部JDK API的库和框架面临破坏性变更，但延长的时间线允许有序过渡。

6.4 模块化Java的未来

企业采用与Java 21使用率的上升保持一致，调查显示43%的开发者在其项目中利用它，表明为了构建可维护、安全的系统，更广泛地集成了模块化实践。

模块系统的未来可能涉及更深入的工具集成、改进的IDE支持以及更清晰的最佳实践。Java 25的JEP 511引入了通过import module M;语法的模块导入声明，允许从导出包中导入所有公共类型以简化使用，显示了向开发者友好的模块交互方向持续演进。

7. 社区治理与OpenJDK流程

7.1 JCP与JEP的关系

JEP流程并未取代Java社区流程，JCP仍然是所有标准Java SE API及相关接口的管理机构，被接受的提案需要通过JSR在JCP中进行并行努力，以实现标准接口的变更。

这种双轨系统平衡了创新与标准化：

• JEP：允许OpenJDK提交者在成为正式的Java规范请求之前更非正式地工作，充当JDK发布项目的长期路线图。
• JSR：定义所有Java实现必须遵循的规范的正规提案，确保跨供应商的一致性。

7.2 决策结构

OpenJDK负责人最终决定将哪些JEP纳入路线图，但在评估提案时依赖评审者、组长和领域负责人所展示的专业知识。这种层级结构承认，没有人能在Java的庞大复杂性中保持专家级的理解。

成功的JEP需要通过评审者背书以及组长/领域负责人支持来建立共识。组长或领域负责人的背书应被视为相当有力的声明，相当于“我将主张这个JEP应该获得资助”。

7.3 六个月发布节奏的影响

JDK 25于2025年9月16日达到通用可用性，其功能和进度通过JEP流程（经JEP 2.0提案修订）进行跟踪。可预测的节奏从根本上改变了Java的创新模式。

此前多年的发布周期造成了将不成熟功能纳入发布窗口的压力。六个月模型允许功能在跨版本的多次预览轮次中成熟，而不会阻碍其他改进。这种能够培养耐心的结构被证明对Valhalla等复杂的举措至关重要，这些举措需要广泛的实际测试才能稳定。

7.4 社区参与

Java社区流程最初于1998年12月正式制定，Java的许多成功归功于该语言的演进方式以及全球社区在此演进中的协作方式。如今的参与机制包括邮件列表、早期访问构建和公共问题跟踪。

透明度要求已有所发展。JSR专家组必须在公共邮件列表上进行讨论，使用公共问题跟踪机制记录进度，并发布工作文档供所有人查看。这种开放性与早期更为封闭的开发模式形成对比。

8. Java的竞争定位

8.1 多范式格局

Java在多条战线上面临竞争，每种竞争都代表了不同的权衡：

• Kotlin：Kotlin势头强劲，特别是在2017年谷歌宣布其为Android开发首选语言之后，不过根据Stack Overflow的2022年调查，Java仍远受欢迎得多（33.27% vs 9.16%）。Kotlin的吸引力在于互操作性——它运行在JVM上，并能与现有Java代码无缝集成，支持渐进式采用而非彻底重写。
• Go：Go专为简单性和并发性设计，针对微服务和云基础设施领域，在这些领域中，快速编译和直接部署比丰富的生态系统更重要。Go的垃圾收集和缺乏泛型（直到最近）代表了倾向于简单性的有意权衡。
• Rust：到2025年，Rust凭借其对内存安全和零成本抽象的强调，已确立自身作为系统编程、WebAssembly和性能关键型应用程序首选语言的地位。Rust陡峭的学习曲线和编译时严格性针对那些安全性和性能值得付出复杂性的场景。

8.2 Java的持久优势

截至2025年，Java仍占据约15%至16%的编程语言市场份额，68%的应用程序运行在Java或JVM上，99%的组织正在积极使用Java。几个因素维持了这一地位：

• 生态系统成熟度：数十年的库开发、框架演进和工具改进创造了难以复制的网络效应。Spring、Jakarta EE、测试框架、构建工具、分析器——完整的开发栈已然存在且运行良好。
• 企业稳定性：框架和库正转向支持或要求更新的Java版本，Java 17已成为新的基线，因为Spring、JUnit、Gradle 9及即将发布的Maven 4要求Java 17或更高版本。这种协调一致的演进在提升能力的同时保持了生态系统的连贯性。
• 性能演进：Java的性能通过JIT进步、垃圾收集器创新以及现在的Project Valhalla和Vector API计划持续改进。对于许多工作负载，与低级语言的性能差距正在缩小。
• 云原生适配：语言间的互操作性使开发者能够将Rust的高性能组件集成到现有的Java程序中，15%的开发者将Java与其Rust项目一起使用。这种多语言方法允许利用每种语言的优势，而非迫使做出全有或全无的选择。

8.3 人工智能与机器学习背景

像Embabel、Koog、Spring AI和LangChain4j这样的新框架推动了AI原生和AI辅助开发在Java中的快速采用。虽然Python在机器学习研究和实验领域占据主导地位，但在生产部署中——可靠性、监控以及与现有系统的集成至关重要的领域——Java的作用依然巨大。

8.4 威胁评估

最大的挑战并非被单一竞争对手取代，而是在专门细分领域中的碎片化。不同的语言针对不同的约束条件进行优化：

• 开发速度：对于追逐产品-市场契合度的MVP和初创公司，Ruby、Python仍然更快
• 本机性能：对于系统编程和嵌入式环境，Rust、C++保持优势
• 简单性：对于优先考虑可维护性而非表达力的团队，Go的极简主义很有吸引力
• 移动端：对于原生平台集成，Swift和Kotlin提供更优体验
  Java的战略似乎是扩大其范围，而非固守单一细分市场。Valhalla针对性能关键场景，Panama支持系统级集成，Amber提高开发者生产力，Vector API解决数值计算问题。这种多线并进的演进旨在使Java在尽可能广泛的使用场景中保持相关性。

9. 结论：我们的收获

在我们审视Java向2026年及以后的轨迹时，几个原则显现出来：

1. 通过更智能的数据表示实现性能：Project Valhalla的值类型解决了Java对象模型与现代硬件之间的根本性架构不匹配问题，展示了3倍的性能改进，可能重塑Java在性能敏感领域的定位。
2. 简化的本地互操作性：Project Panama的外部函数和内存API消除了JNI的复杂性，同时保持类型安全，最终为那些企业系统经常需要的本地集成提供了一种现代机制。
3. 无需仪式感的表达力：Project Amber持续不断的增强——从模式匹配到记录类再到密封类——证明了生产力改进无需牺牲类型安全或运行时性能。
4. 显式并行性：Vector API为开发者提供了对SIMD能力的直接访问，并具有平台无关的抽象，解决了自动向量化无法可靠处理的性能关键场景。
5. 审慎的模块采用：虽然JPMS提供了架构上的好处，但实际采用显示出由特定用例驱动的渐进式进展，而非全盘迁移的压力。
6. 透明的治理：JEP和JCP流程的结合，加上六个月发布节奏的加速，使得在保持稳定性和社区参与的同时能够快速创新。
7. 通过演进保持竞争力：Java通过将能力扩展到相邻领域来维持相关性，而非固守历史优势，这些领域涵盖从低级性能到现代语言特性再到AI集成。

进入2026年的Java平台代表着比仅仅维护遗留系统更有趣的事物。通过对硬件现实、开发者易用性和生态系统演变的密切关注，Java将自己定位为一个能够随着需求变化而成长的平台，而非一个固守过去成功的平台。这种演进方式能否成功应对未来的挑战，将取决于执行情况、社区的响应以及将承诺的功能作为稳定、生产就绪的特性交付而非永久预览的能力。

未来的时间线需要耐心。Valhalla的值类型在2026-2027年之前不会投入生产。Vector API继续孵化以最终定稿。然而，这种审慎的节奏反映了一个成熟的平台，它重视稳定性而非将功能匆忙推向市场。对于构建旨在运行数十年的系统的组织而言，Java谨慎的演进和向后兼容性代表的是资产，而非负债。

【注】本文译自：The Future of Java: What to Expect in 2026 and Beyond

如果你曾编写过多线程Java应用程序，很可能接触过ThreadLocal变量。自Java 1.2引入以来，它已存在超过25年，帮助开发者在线程内共享数据而无需通过每个方法参数传递。但时代在变，Java也在演进。随着虚拟线程和Project Loom的出现，传统的ThreadLocal方式已显陈旧。作用域值（Scoped Values）应运而生：一种更简洁、高效且安全的替代方案，正在重塑我们对线程局部数据的认知。

ThreadLocal的问题：为何需要变革

想象一下：你正在构建一个处理数千个并发请求的Web应用程序。每个请求需要在处理生命周期（从Web控制器到服务层，再到数据访问组件）中携带用户认证信息。传统做法是使用ThreadLocal。

public class ThreadLocalExample {
    private static final ThreadLocal<String> userContext = new ThreadLocal<>();

    public static void main(String[] args) {
        userContext.set("Admin");
        System.out.println("User: " + userContext.get());
        userContext.remove(); // 千万别忘记这一步！
    }
}

但问题在于：ThreadLocal在现代应用中存在以下日益突出的缺陷：

1. 内存泄漏隐患
   必须手动调用remove()，否则可能导致内存泄漏。忘记清理？随着线程不断累积废弃值，你的应用会逐渐耗尽内存。这就像离开每个房间后都不关灯——最终会导致电路过载。

2. 可变性混乱
   ThreadLocal值可在任意位置、任意时间被修改。这种“远距离幽灵作用”（借用爱因斯坦描述量子力学的比喻）使得调试极其困难。哪个方法修改了值？何时修改？为何修改？在复杂的调用链中追踪这些问题如同大海捞针。

3. 昂贵的继承开销
   当父线程使用InheritableThreadLocal创建子线程时，整个线程局部映射会被复制。对于虚拟线程（可能同时存在10万个线程），这种内存压力将无法承受。

4. 生命周期模糊
   ThreadLocal值会持续存在于线程的整个生命周期，除非显式移除。数据应在何处可访问、何处不可访问的边界并不清晰。

作用域值：我们需要的解决方案

作为Java 20的孵化器功能引入，并在Java 21和22中持续优化，作用域值解决了ThreadLocal的所有痛点，同时为虚拟线程时代量身定制。

作用域值的不同之处
可将作用域值视为ThreadLocal更智能、更规范的“兄弟”。其核心变革如下：

import java.lang.ScopedValue;

public class ScopedValuesExample {
    private static final ScopedValue<String> USER_CONTEXT = ScopedValue.newInstance();

    public static void main(String[] args) {
        ScopedValue.where(USER_CONTEXT, "Admin").run(() -> {
            System.out.println("User: " + USER_CONTEXT.get());
            processRequest(); // 嵌套调用中值仍可访问
        });
        // USER_CONTEXT 在此自动清理！无需手动清除
    }

    private static void processRequest() {
        System.out.println("仍可访问: " + USER_CONTEXT.get());
    }
}

这里发生了什么？值“Admin”仅在run() lambda作用域内绑定到USER_CONTEXT。一旦作用域结束，值会自动消失。无需手动清理，没有内存泄漏，只有清晰可靠的行为。

核心原则：为何作用域值更优

1. 设计上的不可变性
   一旦将值绑定到ScopedValue，在该作用域内就无法更改。这不是限制，而是特性——它消除了因意外变更导致的整类错误。

ScopedValue.where(USER_CONTEXT, "Admin").run(() -> {
    // 不存在set()方法！
    // 值在整个作用域内保持为"Admin"
    callServiceLayer();
    callDataAccessLayer();
    // 所有方法看到相同且不变的值
});

2. 显式的有限生命周期
   代码的语法结构清晰展示了数据的可访问范围。看到那些花括号了吗？那就是作用域，也是值的存活范围。超出之后，值即消失。

这不仅是内存管理问题，更关乎认知负荷。你可以一眼理解数据流，无需在代码中费力追踪ThreadLocal值可能被修改或清理的位置。

3. 极速性能
   由于不可变性，JVM可以积极优化作用域值的访问。无论方法调用嵌套多深，通过get()读取作用域值的速度通常堪比读取局部变量。该实现采用轻量级缓存机制，使得重复访问几乎零开销。

对虚拟线程而言，这一点至关重要。在可能存在数百万个并发线程的情况下，每个字节和每个CPU周期都至关重要。

4. 零成本继承
   当将作用域值与结构化并发（Java 21的另一预览功能）结合使用时，子线程会自动继承父线程的值。但神奇之处在于：由于值不可变，没有复制开销，本质上只是传递指针。

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

ScopedValue.where(REQUEST_ID, "REQ-12345").run(() -> {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        // 子线程自动看到REQUEST_ID
        scope.fork(() -> processPartA());
        scope.fork(() -> processPartB());
        scope.join();
    }
});

processPartA()和processPartB()都能看到“REQ-12345”且无需任何复制。用ThreadLocal可无法高效实现这一点！

实际案例：构建Web框架上下文

让我们通过一个实际场景（处理包含用户认证和事务管理的Web请求）来展示作用域值的优势：

public class WebFramework {
    private static final ScopedValue<Principal> LOGGED_IN_USER = ScopedValue.newInstance();
    private static final ScopedValue<Connection> DB_CONNECTION = ScopedValue.newInstance();

    public void handleRequest(Request request) {
        Principal user = authenticate(request);
        Connection conn = getConnection();

        ScopedValue.where(LOGGED_IN_USER, user)
                   .where(DB_CONNECTION, conn)
                   .run(() -> {
                       processRequest(request);
                   });

        // conn和user自动清理
    }

    private void processRequest(Request request) {
        // 调用链中的任何方法均可访问这些值
        Principal currentUser = LOGGED_IN_USER.get();
        Connection db = DB_CONNECTION.get();

        // 业务逻辑在此处理
        serviceLayer.process();
        dataAccessLayer.save();
    }
}

注意我们无需进行以下操作：

• 无需通过每个方法参数传递user和conn
• 无需手动清理代码
• 无需担心其他方法修改这些值
• 即使抛出异常也不会内存泄漏

框架处理请求、绑定必要上下文、通过各层处理请求，并在完成后自动清理。非常优雅。

多线程示例：随机数生成

以下完整示例展示不同线程如何获取各自的作用域值：

import java.lang.ScopedValue;
import java.util.concurrent.Executors;

public class MultiThreadExample {
    private static final ScopedValue<Integer> RANDOM_NUMBER = ScopedValue.newInstance();

    public static void main(String[] args) {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < 10; i++) {
                executor.submit(() -> {
                    int randomValue = (int) (Math.random() * 100);
                    ScopedValue.where(RANDOM_NUMBER, randomValue).run(() -> {
                        System.out.println(Thread.currentThread().getName() + 
                                         ": 随机数: " + RANDOM_NUMBER.get());
                        doSomeWork();
                    });
                });
            }
        }
    }

    private static void doSomeWork() {
        // 此处仍可访问RANDOM_NUMBER
        System.out.println("正在处理: " + RANDOM_NUMBER.get());
    }
}

每个虚拟线程获取自己的随机数，并在其作用域内可访问。简单、清晰、高效。

作用域值 vs. ThreadLocal：何时使用

以下情况，使用作用域值

• 使用虚拟线程（Project Loom）
• 需要共享不可变上下文数据（用户信息、请求ID、事务上下文）
• 需要自动清理和有限生命周期
• 使用结构化并发并需要高效的子线程继承
• 希望代码更易理解和维护

以下情况，继续使用ThreadLocal

• 需要真正的每线程可变存储
• 缓存创建成本高的对象（如DateFormat实例）
• 处理无法重构的遗留系统
• 数据确实需要在线程整个生命周期内持久存在

技术深度解析：实际工作原理

在底层，作用域值采用复杂但轻量的实现，涉及两个关键组件：

• 载体（Carrier）：保存ScopedValue与其实际值之间的绑定
• 快照（Snapshot）：在特定时间点捕获所有绑定的状态

当你调用ScopedValue.where(KEY, value).run(...)时，JVM会创建一个新的载体来关联该键值对。ScopedValue对象本身如同映射键——一个用于在载体栈中查找值的唯一指针。

其精妙之处在于缓存：首次调用get()时，会搜索外围作用域以找到绑定，然后将结果缓存到小型线程局部缓存中。后续访问速度极快——可能堪比读取局部变量。

专业提示：如需绑定多个值，可创建记录类来保存它们，并将单个ScopedValue绑定到该记录实例。这能最大化缓存效率：

record RequestContext(Principal user, Connection db, String requestId) {}

private static final ScopedValue<RequestContext> CONTEXT = ScopedValue.newInstance();

ScopedValue.where(CONTEXT, new RequestContext(user, conn, "REQ-123"))
           .run(() -> processRequest());

现状与未来

截至2025年11月，作用域值已从孵化器（Java 20）经过预览状态（Java 21、22），并有望成为永久功能。该API在多个预览周期中保持稳定，表明其已接近正式发布。

在Java 21-23中使用作用域值，当前需要启用预览功能：

javac --release 23 --enable-preview YourProgram.java
java --enable-preview YourProgram

一旦功能定稿（可能在Java 24或25），将不再需要预览标志。

结论

作用域值代表了对多线程Java应用中数据共享方式的根本性重新思考。通过拥抱不可变性、显式作用域和性能优化，它们解决了ThreadLocal的所有主要弱点，同时完美适应虚拟线程革命。

你无需急于替换代码库中的每个ThreadLocal。但对于新代码——尤其是为虚拟线程和结构化并发设计的代码——作用域值应是默认选择。它们更安全、更快速、更清晰、更易维护。

明确的信息是：对于面向虚拟线程和结构化并发的新Java应用，作用域值应成为共享上下文数据的首选。它们使代码更安全、更快速，且显著更易理解。

Java并发的未来已至，而且拥有精美的作用域。

本文要点总结

在服务超过25年后，ThreadLocal在现代Java应用中显现出明显局限性。手动清理要求带来内存泄漏风险，可变性导致意外状态变化，继承机制开销昂贵，生命周期模糊不清——这些问题在使用虚拟线程时尤为突出。

作用域值通过其核心设计解决了这些问题。它们提供自动生命周期管理以消除内存泄漏顾虑，不可变性防止意外变更，有限作用域使数据生命周期显式化。性能表现强劲，通过优化缓存实现快速访问，高效的继承机制允许与子线程零成本共享值。

编程模型以显式作用域为核心。值通过ScopedValue.where(KEY, value).run(...)绑定，在嵌套方法调用中自动可访问，并在作用域结束时自动清理。这种方法与虚拟线程（JEP 444）和结构化并发（JEP 453）良好集成，为现代并发编程创建了连贯的基础。

性能特性适合实际使用。通过智能缓存，读取作用域值的速度接近局部变量，轻量级实现可处理数百万虚拟线程而无ThreadLocal的内存压力。常见用例包括Web请求上下文、用户认证数据、事务管理、请求追踪，以及任何需要通过调用链传播不可变上下文的场景。

作用域值和ThreadLocal之间的选择取决于需求。作用域值适用于现代代码中的不可变上下文共享，而ThreadLocal仍适用于每线程可变缓存和遗留系统。该功能从Java 20的孵化器状态演进至Java 21-23的预览阶段，API稳定性表明它即将成为永久功能。

当需要绑定多个值时，将它们分组到记录类并绑定单个ScopedValue可最大化缓存效率并简化代码。更广泛地说，作用域值代表了向更安全、更易理解的并发编程的转变，与Java向轻量级、高并发应用发展的方向一致。

【注】本文译自：Scoped Values: The Modern Alternative to ThreadLocal That Java Developers Have Been Waiting For