解决 Java 9 模块化带来的 `Unable to make protected native java.lang.Object java.lang.Object.clone()` 问题

随着 Java 9 引入模块化系统（Java Platform Module System，JPMS），开发者可以更加高效地管理和维护模块化的代码。然而，模块化也带来了一些兼容性问题，尤其是在使用反射或访问 JDK 内部 API 时，可能会遇到 Unable to make protected native java.lang.Object java.lang.Object.clone() 错误。

本篇博客将详细解释这一问题的产生原因，并提供解决方法。

---

为什么会出现 Unable to make protected native java.lang.Object java.lang.Object.clone() 错误？

在 Java 9 及以上版本中，Java 引入了 强封装，这意味着许多 JDK 内部的 API 被封装并且不能被外部模块访问。例如，java.lang.Object.clone() 方法是一个受保护的方法，在 Java 8 中可以通过反射访问，但在 Java 9 中由于模块化的引入，它被封装在 java.base 模块内，外部模块无法直接访问。

这就是为什么在 Java 9 或更高版本中，如果你的代码或依赖库尝试通过反射访问 java.lang.Object.clone() 方法时，会抛出如下错误：

Unable to make protected native java.lang.Object java.lang.Object.clone()

对模块化感兴趣的同学可以参考这篇文章：Java9模块化相关知识

模块化如何影响反射访问？

Java 9 的模块化将 JDK 中的一些包进行了封装，默认情况下，这些包无法被外部模块访问。例如，java.lang 包和其中的许多类（包括 Object 类）都被封装在 java.base 模块内，因此，如果外部模块尝试访问这些类或其方法，就会受到限制。

在传统的类路径模式下，JVM 对所有类和方法的访问没有这么严格的限制，开发者可以随意使用反射访问任何类中的方法。但在模块化的 Java 9 中，如果没有显式地开放模块或包，外部模块无法访问这些内部的 API，这导致了反射访问问题的出现。

如何解决这个问题？

Java 9 引入了模块化系统后，默认的强封装会导致反射访问受保护方法时发生错误。解决这个问题的最简单方法是通过 Java 启动参数 --add-opens 来开放特定模块的包。具体来说，你可以在启动时添加以下参数：

--add-opens java.base/java.lang=ALL-UNNAMED

这个参数的作用是将 java.base 模块中的 java.lang 包开放给所有未命名模块（ALL-UNNAMED）。未命名模块指的是那些没有 module-info.java 文件的代码，通常是使用类路径的旧代码或第三方库。

举个例子：

假设你遇到了 Unable to make protected native java.lang.Object java.lang.Object.clone() 错误，并且你需要通过反射访问 Object.clone() 方法，可以在运行时通过添加以下启动参数来解决问题：

java --add-opens java.base/java.lang=ALL-UNNAMED -jar your-application.jar

此时，JVM 会在启动时开放 java.base/java.lang 包的访问权限，允许你在运行时通过反射访问 Object.clone() 方法。

启动参数解释

• --add-opens：用于将指定的包开放给某些模块。此参数接受两个参数：第一个是模块名称，第二个是要开放的包名。
• java.base/java.lang：表示 java.base 模块中的 java.lang 包。在 Java 9 中，java.base 模块包含了 Java 核心库，包括 java.lang 包。
• ALL-UNNAMED：表示将该包开放给所有没有定义模块描述符的模块，即没有 module-info.java 文件的模块。

何时使用 --add-opens 参数？

通常来说，你应该尽量避免依赖 --add-opens 参数，因为它是绕过模块封装的一种方式，可能会带来一些安全隐患或兼容性问题。推荐的做法是尽可能使用公开的 API 和模块化的设计，避免直接访问 JDK 内部的方法或类。

然而，在某些情况下，特别是当你需要维护旧代码或使用第三方库时，可能无法立即迁移到模块化体系中，这时候可以通过 --add-opens 参数来解决临时的兼容性问题。

示例：修复反射问题

假设你正在使用反射来访问 Object.clone() 方法，代码如下：

import java.lang.reflect.Method;

public class ReflectionExample {
    public static void main(String[] args) throws Exception {
        Object obj = new Object();
        Method method = Object.class.getDeclaredMethod("clone");
        method.setAccessible(true);
        Object clonedObj = method.invoke(obj);
        System.out.println(clonedObj);
    }
}

在 Java 8 中，这段代码可以正常运行，但在 Java 9 及以上版本中会抛出 Unable to make protected native java.lang.Object java.lang.Object.clone() 错误。为了让代码能够运行，你可以在启动时加上 --add-opens 参数：

java --add-opens java.base/java.lang=ALL-UNNAMED -cp . ReflectionExample

其他可能的解决方案

除了使用 --add-opens，你还可以考虑以下几种方案来避免这个问题：

• 使用 --add-exports：如果你的代码依赖某个模块中的特定包而不是所有包，可以使用 --add-exports 来导出特定的包。
• 修改代码：如果可能，避免使用反射来访问 clone() 等受保护的方法，而是使用公开的 API。
• 升级依赖：如果这个问题是由第三方库引起的，检查是否有更新的库版本已兼容模块化系统，或者尝试联系库的开发者进行修复。

总结

Java 9 引入的模块化系统带来了更强的封装性，虽然在提升系统安全性和可维护性的同时，也引发了一些兼容性问题。特别是在使用反射访问 JDK 内部 API 时，开发者可能会遇到 Unable to make protected native java.lang.Object java.lang.Object.clone() 错误。

解决这个问题的最简单方法是通过启动参数 --add-opens 来开放特定的包。虽然这是一种临时的解决方案，但它能够帮助开发者快速解决模块化带来的反射问题。尽管如此，最佳实践仍然是尽量避免直接访问 JDK 内部的类和方法，尽可能使用公开的 API。

如果你遇到了类似的兼容性问题，欢迎留言讨论，共同探讨最佳的解决方案！