This paper describes a process for the semi-automatic conversion of numerical and scientific routines written in the C programming language into Triana-based computational services that can be used within a distributed serviceoriented architecture such as that being adopted for Grid computing. This process involves two separate but related tools, JACAW and MEDLI. JACAW is a wrapper tool based on the Java Native Interface (JNI) that can automatically generate the Java interface and related files for any C routine, or library of C routines. The MEDLI tool can then be used to assist the user in describing the mapping between the Triana and C data types involved in calling a particular routine. In this paper we describe both JACAW and MEDLI, and demonstrate how they are used in practice to convert legacy code into Grid services. 1.

Type safety is a promising approach to enhancing software security. Programs written in type-safe programming languages such as Java are type-safe by construction. However, in practice, many complex applications are heterogeneous, i.e., they contain components written in different languages. The Java Native Interface (JNI) allows type-safe Java code to interact with unsafe C code. When a type-safe language interacts with an unsafe language in the same address space, in general, the overall application becomes unsafe. In this work, we propose a framework called Safe Java Native Interface (SafeJNI) that ensures type safety of heterogeneous programs that contain Java and C components. We identify the loopholes of using JNI that would permit C code to bypass the type safety of Java. The proposed SafeJNI system fixes these loopholes and guarantees type safety when native C methods are called. The overall approach consists of (i) retro-fitting the native C methods to make them safe, and (ii) developing an enhanced system that captures additional invariants that must be satisfied to guarantee safe interoperation. The SafeJNI framework is implemented through a combination of static and dynamic checks on the C code. We have measured our system’s effectiveness and performance on a set of benchmarks. During our experiments on the Zlib open source compression library, our system identified one vulnerability in the glue code between Zlib and Java. This vulnerability could be exploited to crash a large number of commercially deployed Java Virtual Machines (JVMs). The performance impact of SafeJNI on Zlib, while considerable, is less than reimplementing the C code

In this paper, we describe static analysis techniques for finding bugs in programs using the Java Native Interface (JNI). The JNI is both tedious and error-prone because there are many JNI-specific mistakes that are not caught by a native compiler. This paper is focused on four kinds of common mistakes. First, explicit statements to handle a possible exception need to be inserted after a statement calling a Java method. However, such statements tend to be forgotten. We present a typestate analysis to detect this exception-handling mistake. Second, while the native code can allocate resources in a Java VM, those resources must be manually released, unlike Java. Mistakes in resource management cause leaks and other errors. To detect Java resource errors, we used the typestate analysis also used for detecting general memory errors. Third, if a reference to a Java resource lives across multiple native method invocations, it should be converted into a global reference. However, programmers sometimes forget this rule and, for example, store a local reference in a global variable for later uses. We provide a syntax checker that detects this bad coding practice. Fourth, no JNI function should be called in a critical region. If called there, the current thread might block and cause a deadlock. Misinterpreting the end of the critical region, programmers occasionally break this rule. We present a simple typestate analysis to detect an improper JNI function call in a critical region. We have implemented our analysis techniques in a bug-finding tool called BEAM, and executed it on opensource software including JNI code. In the experiment, our analysis techniques found 86 JNI-specific bugs without any overhead and increased the total number of bug reports by 76%.

Abstract. Continuously evolving Java technology provides effective solutions for many industrial and scientific computing challenges. These solutions, however, often require cooperation between Java and native languages. It is possible to achieve such interoperability using the Java Native Interface (JNI); however, this facility introduces an overhead which must be considered while developing interface code. This paper presents JNI performance benchmarks for several popular Java Virtual Machine implementations. These may be useful in avoiding certain JNI pitfalls and provide a better understanding of JNI-related performance issues. 1