Java 11+中jdk.nashorn包缺失导致注解无法使用

Question

在Java 11及以上版本中，`jdk.nashorn`包被移除，导致依赖该包的注解处理器或运行时反射逻辑失效。常见问题如自定义注解结合脚本引擎进行动态处理的场景下，因`NashornScriptEngine`不可用而抛出`NoClassDefFoundError`。尤其在旧有框架升级过程中，若未替换替代方案（如GraalVM Polyglot），会导致注解驱动功能全面中断，亟需迁移与适配。

Answer 1

Java 11+ 中 jdk.nashorn 移除问题的深度解析与迁移方案

1. 背景与问题引入

自 Java 11 起，Oracle 正式移除了 jdk.nashorn 包，标志着 Nashorn JavaScript 引擎的终结。这一变更对依赖其进行脚本动态执行、尤其是结合注解处理器或运行时反射机制的应用产生了深远影响。

典型场景中，开发者常使用自定义注解（如 @Scriptable 或 @DynamicEval）标记类或方法，并在运行时通过 ScriptEngineManager 获取 NashornScriptEngine 执行 JS 逻辑。然而，在 Java 11 及以上版本中，此类代码将抛出：

java.lang.NoClassDefFoundError: jdk/nashorn/api/scripting/NashornScriptEngine

这不仅影响功能可用性，更在框架升级过程中引发连锁反应。

2. 核心技术演变时间线

Java 版本	JavaScript 引擎支持	关键变化
Java 8	Nashorn（jdk.nashorn）	取代 Rhino，基于 JVM 的高性能 JS 引擎
Java 9	标记为 deprecated	--add-modules java.se.ee 需显式启用
Java 11	完全移除	jdk.nashorn.* 不再存在
Java 14+	GraalVM Polyglot 推荐	支持多语言嵌入式执行

3. 典型故障场景分析

• 注解处理器失效：APT（Annotation Processing Tool）阶段尝试加载 Nashorn 类型导致编译中断。
• 运行时反射调用失败：通过 Class.forName("jdk.nashorn.api.scripting.NashornScriptEngine") 动态加载失败。
• 框架兼容性断裂：Spring、Apache Commons 等第三方库若未更新，可能间接依赖该包。
• 条件编译误判：部分项目使用版本判断跳过初始化，但未正确隔离类引用。

4. 迁移路径与替代方案对比

主流替代方案评估表

方案	兼容性	性能	维护状态	适用场景
GraalVM Polyglot	✅ Java 8+	⭐⭐⭐⭐☆	actively maintained	生产级多语言集成
Mozilla Rhino	✅ Java 8+	⭐⭐☆☆☆	maintenance mode	轻量脚本需求
JavascriptEngine (J2V8)	⚠️ 需 V8 原生库	⭐⭐⭐⭐★	limited updates	Node.js 互操作
Janino + 自定义 DSL	✅ 纯 Java	⭐⭐⭐☆☆	stable	表达式求值替代

5. GraalVM Polyglot 实现迁移示例

以自定义注解 @JsEval 结合 GraalVM 替代原 Nashorn 实现为例：

import org.graalvm.polyglot.*;

public class ScriptEvaluator {
    private static final Context context = Context.newBuilder("js")
        .option("js.ecmascript-version", "2021")
        .build();

    public Object eval(String script) {
        return context.eval("js", script);
    }
}

// 注解处理器中调用
@JsEval(script = "function(x) { return x * 2; }")
public int doubleValue(int input) {
    String jsFunc = extractFromAnnotation();
    Value func = new ScriptEvaluator().eval(jsFunc);
    return func.execute(input).asInt();
}

6. 架构级适配策略流程图

graph TD
    A[检测到 NoClassDefFoundError] --> B{是否使用 jdk.nashorn?}
    B -- 是 --> C[隔离旧逻辑模块]
    C --> D[引入 GraalVM polyglot 依赖]
    D --> E[重构 ScriptEngine 初始化]
    E --> F[替换所有 Nashorn API 调用]
    F --> G[添加运行时环境检测]
    G --> H[自动化测试验证]
    H --> I[部署灰度发布]
    B -- 否 --> J[检查间接依赖]
    J --> K[使用 jdeps 分析依赖树]

7. 编译期与运行期兼容性处理技巧

对于需跨 Java 8/11+ 兼容的项目，可采用服务发现模式：

public interface ScriptEngineProvider {
    Object eval(String script);
}

@Service
public class NashornProvider implements ScriptEngineProvider {
    // Java 8 下使用
}

@Service
public class GraalVmProvider implements ScriptEngineProvider {
    // Java 11+ 使用
}

// 工厂模式选择
public class ScriptEngineFactory {
    public static ScriptEngineProvider get() {
        try {
            Class.forName("jdk.nashorn.api.scripting.NashornScriptEngine");
            return new NashornProvider();
        } catch (ClassNotFoundException e) {
            return new GraalVmProvider();
        }
    }
}

8. 工具链辅助检测建议

• 使用 jdeps --class-path your-app.jar 检查对 jdk.nashorn 的显式引用。
• 在 CI 流程中加入 javac -Xlint:deprecation 提示废弃 API 使用。
• 引入 Animal Sniffer 检测非法 API 调用。
• 利用 ArchUnit 编写规则禁止 com.tngtech.archunit.core.domain.JavaClasses 中包含特定包引用。

9. 社区生态与长期演进趋势

随着 GraalVM 成为 OpenJDK 生态的重要组成部分，Polyglot API 正逐步标准化。未来可通过 org.graalvm.sdk 实现跨语言互操作，包括 Python、Ruby、R 等。此外，Project Leyden 正探索静态镜像构建，将进一步推动原生镜像中脚本引擎的集成方式革新。

社区已出现如 graaljs-jdk11 的 backport 方案，允许在非 GraalVM 的 HotSpot 上运行 GraalJS，增强了迁移灵活性。