Java Native Interface (JNI) allows Java applications to access native libraries, but it is challenging to develop correct JNI programs. By leveraging native code, the JNI enables Java developers to implement efficient applications and reuse code written in other programming languages such as C and C++. The core Java libraries use the JNI to provide system features like graphical user interfaces, and mainstream Java Virtual Machines (JVMs) support the JNI. However, implementing correct JNI programs is not trivial due to the complex interoperation semantics between different programming languages. While JVMs do not validate JNI interoperations by default because of the performance overhead, they provide two methods. First, JVMs report the interoperation failures defined in the JNI specification at runtime. Second, they support a debug option, which validates JNI interoperations, degrading the runtime performance. To the best of our knowledge, literature has not thoroughly studied the quality of JVMs’ methods, even though erroneous JNI interoperations may result in incorrect behaviors. In this paper, we empirically study the behaviors of JVMs on erroneous JNI interoperations. For a systematic study, we propose JUSTGen , a semi-automatic tool that generates JNI test programs incurring erroneous interoperations from the JNI specification. JUSTGen receives the JNI specification written in our domain-specific language (DSL) and automatically discovers cases that may lead to runtime errors on interoperations using an SMT solver. It then generates test programs that trigger the behaviors on the erroneous cases. Using the generated tests, we empirically evaluate JVM's failure handling mechanisms and the debug option capabilities on erroneous JNI interoperations. Our experiment results show that there exist erroneous cases in which JVMs do not handle failures or handle them differently from the specification. We also found that the JNI debug option does not validate thousands of erroneous cases, which can cause critical runtime errors such as memory corruption and violation of the Java type system. We reported 18 erroneous cases of which JVMs do not handle failures correctly to their respective vendors. Among them, 16 cases have been resolved.

中文翻译：

---

JVM 对错误 JNI 互操作的行为的实证研究

Java 本机接口 (JNI) 允许 Java 应用程序访问本机库，但开发正确的 JNI 程序具有挑战性。通过利用本机代码，JNI 使 Java 开发人员能够实现高效的应用程序并重用用其他编程语言（例如 C 和 C++）编写的代码。核心Java库使用JNI来提供图形用户界面等系统功能，主流Java虚拟机（JVM）都支持JNI。然而，由于不同编程语言之间复杂的互操作语义，实现正确的 JNI 程序并非易事。虽然由于性能开销，JVM 默认情况下不验证 JNI 互操作，但它们提供了两种方法。首先，JVM 在运行时报告 JNI 规范中定义的互操作失败。其次，它们支持调试选项，该选项可验证 JNI 互操作，从而降低运行时性能。据我们所知，文献尚未彻底研究 JVM 方法的质量，尽管错误的 JNI 互操作可能会导致不正确的行为。在本文中，我们实证研究了 JVM 在错误 JNI 互操作上的行为。为了进行系统研究，我们建议JUSTGen 是一种半自动工具，可生成 JNI 测试程序，从而导致 JNI 规范中的互操作错误。JUSTGen 接收用我们的领域特定语言 (DSL) 编写的 JNI 规范，并使用 SMT 求解器自动发现可能导致互操作运行时错误的情况。然后，它生成测试程序，在错误情况下触发行为。使用生成的测试，我们凭经验评估 JVM 的故障处理机制以及错误 JNI 互操作的调试选项功能。我们的实验结果表明，存在 JVM 不处理故障或以与规范不同的方式处理故障的错误情况。我们还发现 JNI 调试选项不会验证数千个错误情况，这可能会导致严重的运行时错误，例如内存损坏和违反 Java 类型系统。我们向各自的供应商报告了 18 个 JVM 未正确处理故障的错误案例。其中，已解决16起案件。