Java 社区正在推进一项名为“JEP 472：Prepare to Restrict the Use of JNI（准备限制 JNI 使用）”的提案，旨在保留 Java Native Interface (JNI) 作为与本地代码互操作的标准方式的状态。
JNI 在 JDK 1.1（可追溯到 1997 年 2 月）中被引入，作为 Java 代码与本地代码（通常用 C 语言编写）之间互操作的主要手段，允许 Java 代码调用本地代码（向下调用）和本地代码调用 Java 代码（向上调用）。
但提案指出，Java 代码和本地代码之间的任何交互都存在风险，它可能会损害应用程序和 Java 平台本身的完整性。根据默认完整性策略，所有能够破坏完整性的 JDK 功能都必须获得应用程序开发人员的明确批准。
准备限制 JNI 的使用是确保 Java 平台默认完整性的长期协调努力的一部分。其他相关举措还包括删除 sun.misc.Unsafe 中的内存访问方法（JEP 471）和限制代理的动态加载（JEP 451）。
该提案由 Ron Pressler 提出，于 2023 年 5 月创建，并于 7 月 16 日更新，计划在预计于 2025 年 3 月推出的 JDK 24 中更新发布。
提案要求对 JNI 的使用发出警告，并调整 Foreign Function & Memory (FFM) API 以一致的方式发出警告。所有这些警告的目的在于让开发人员做好准备，即未来版本中将默认禁止与本地代码互操作，无论是通过 JNI 还是 FFM API。开发人员可以在必要时有选择地启用这些接口。
同时，提案还计划协调 JNI 和 FFM API 的使用，以便库维护人员可以从一个迁移到另一个，而无需开发人员更改任何命令行选项。而弃用 JNI 或从 Java 平台中删除 JNI，以及限制通过 JNI 调用的本地代码的行为均不包含在目标范围内。所有本地 JNI 函数仍可供本地代码使用。
更多详情可查看：https://openjdk.org/jeps/472
评论删除后，数据将无法恢复
OpenJDK 计划要求限制 JNI 的使用
Java 社区正在推进一项名为“JEP 472：Prepare to Restrict the Use of JNI（准备限制 JNI 使用）”的提案，旨在保留 Java Native Interface (JNI) 作为与本地代码互操作的标准方式的状态。
JNI 在 JDK 1.1（可追溯到 1997 年 2 月）中被引入，作为 Java 代码与本地代码（通常用 C 语言编写）之间互操作的主要手段，允许 Java 代码调用本地代码（向下调用）和本地代码调用 Java 代码（向上调用）。
但提案指出，Java 代码和本地代码之间的任何交互都存在风险，它可能会损害应用程序和 Java 平台本身的完整性。根据默认完整性策略，所有能够破坏完整性的 JDK 功能都必须获得应用程序开发人员的明确批准。
准备限制 JNI 的使用是确保 Java 平台默认完整性的长期协调努力的一部分。其他相关举措还包括删除 sun.misc.Unsafe 中的内存访问方法（JEP 471）和限制代理的动态加载（JEP 451）。
该提案由 Ron Pressler 提出，于 2023 年 5 月创建，并于 7 月 16 日更新，计划在预计于 2025 年 3 月推出的 JDK 24 中更新发布。
提案要求对 JNI 的使用发出警告，并调整 Foreign Function & Memory (FFM) API 以一致的方式发出警告。所有这些警告的目的在于让开发人员做好准备，即未来版本中将默认禁止与本地代码互操作，无论是通过 JNI 还是 FFM API。开发人员可以在必要时有选择地启用这些接口。
同时，提案还计划协调 JNI 和 FFM API 的使用，以便库维护人员可以从一个迁移到另一个，而无需开发人员更改任何命令行选项。而弃用 JNI 或从 Java 平台中删除 JNI，以及限制通过 JNI 调用的本地代码的行为均不包含在目标范围内。所有本地 JNI 函数仍可供本地代码使用。
更多详情可查看：https://openjdk.org/jeps/472