Moderator (MDR): MDR-nancy

Guest Speaker (SPK): SPK-name

MDR-nancy: Welcome to our forum on the Java Native Interface (JNI). Our guest today is Sheng Liang. Sheng, can you give us some background about what you are working on at JavaSoft^TM?

SPK-Sheng: Good morning! I'm a member of the Java Virtual Machine¹ development team. I've been working on a variety of VM/runtime related issues, such as the Java Native Interface.

MDR-nancy: What are some issues with using the Java Native Interface?

SPK-Sheng: Java is rapidly becoming a serious application development language. However, there are still situations where a programmer may want to write in another language such as C and C++. Java Native Interface enables programmers to leverage their existing investment into C and C++, while benefiting from Java immediately.

MDR-nancy: If you have questions, please send them in.

SPK-Sheng: The Java Native Interface is shipped with JDK 1.1.

MDR-nancy Here's our first question from jdnbor.

jdnbor: Most of the current docs on JNI focus on calling Java from C and C++. I am interested in Java-wrapping legacy code, especially Win32 APIs for some install-related activities like Registry. Could you say something about how C and C++ types, especially char*, struct*, and function*, map to Java types if at all?

SPK-Sheng: The JNI also allows you to call C and C++ code from Java. On the Java side, you need to declare a special method called native methods. On the C and C++ side, you'll provide the implementation for native methods. The JNI tutorial on our web site contains detailed step-by-step instructions on how to write a JNI native method. The second part of your question--to map C and C++ types, such as char* and struct*, to Java, you need to create a "peer" class in Java, which stores the C pointers as an integer. The constructor can then call malloc to initialize the C data structure, and the finalizer will free it when the object is no longer in use.

MDR-nancy: Afeinman has a question.

afeinman: With all these new add-on pieces (Java 2-D, 3-D, Commerce, etc.), do you see the native interface as becoming less and less important? Or do you think that with the enormous body of existing code in other languages, it will remain important for some time to come?

SPK-Sheng: We hope that as the Java Platform becomes more and more mature, native methods will lose their significance. However, it is more likely that Java code will coexist with C and C++ code in the forseeable future. We are committed to make the Java, C, and C++ integration as painless as possible.

MDR-nancy: These are good questions. Here is one from ErikaStuart.

ErikaStuart: When will JNI work on the Mac?

SPK-Sheng: As a JDK 1.1 feature, the JNI will be supported on the Mac when JDK 1.1 is shipped on the Mac. The JNI is designed so that it can be easily supported on all Java VMs on a wide variety of platforms. There should not be any technical difficulty in supporting it on the Mac.

MDR-nancy: Here's one from rgould about JNI on Solaris.

rgould: The JNI doesn't seem to fully support multithreading on Solaris 2.4 or 2.5. When will this be available? Are there any issues that I should be made aware of regarding the integration of multithreaded C, C++, and Java.

SPK-Sheng: You are right. On Solaris we use a user-level thread package ("green threads") to implement the Java VM. As a result, the entire system may have problems when you try to link with certain multithreaded native libraries. The underlying reason is that the Java VM interposes a certain set of Solaris system calls, in order to support Java-level multithreading. The interposed system calls may not behave in exactly the same way you are used to--they are designed specifically for Java. We will ship a native thread-based Java VM in the near future. (In fact, SunSoft is shipping a Beta version now.) Once that happens, all these problems will go away.

MDR-nancy: On a different note, does the JavaBeans bridge use JNI?

SPK-Sheng: Yes, it does. The JavaBeans/ActiveX bridge allows you to embed a Bean inside an ActiveX container, such as Visual Basic. The Beans/ActiveX bridge translates all ActiveX calls into Java calls through the JNI method-call mechanism.

MDR-nancy: Erika has a question about the best way to debug native code.

ErikaStuart: I was writing some native code where I forgot to return a value. The result was a SEGV. Granted, this was a coding mistake on my part, but finding the error was a little tedious. What is the best way to debug native code, and is there a way to have something other then a SEGV result in this scenario in the JNI?

SPK-Sheng: But this is how folks have been doing C and C++ development for years! (At least you didn't have to reboot the machine like I had to do on a DOS/Windows3.1 system :-) We have to be really careful when we develop in native code. All Java built-in mechanisms on type safety and protection are no longer effective. Native methods essentially become part of the VM. The JNI is designed to minimize the number of mistakes you can make developing native methods. Still, you have to be really careful.

MDR-nancy: So, when is a good situation to use JNI since you are in danger of losing platform independence with Java?

SPK-Sheng: The JNI has to be the last resort. If your application contains even one native method, the application is no longer 100% pure, and you'll lose many of the benefits of Java. However, if you absolutely need to access certain plaform-dependent features available in the standard Java library; or you have a large body of existing code in C and C++ that you do not want to throw away; or you are certain that you cannot get the performance you need with the current Java compilation technology; you may use native methods.

MDR-nancy: Do other vendors provide native method interfaces to Java, and how do they compare to what JNI has to offer?

SPK-Sheng: Yes. The problem is that each Java VM vendor provides a different native method interface. They are not compatible with each other. For example, you cannot load a native method written in Microsoft's Raw Native Interface into Netscape Navigator, which supports Netscape's Java Runtime Interface. The JNI is designed so that it can be easily supported on different VMs from different vendors. We worked with all Java licensees to make sure that this is the case.

MDR-nancy: We have time for a few more questions. Here is one from afeinman.

afeinman: What was the JNI written in?

SPK-Sheng: The JNI is an integral part of the Java Virtual Machine. As such, it can be implemented in any language suitable for implementing the VM, such as C, C++, or even assembly.

MDR-nancy: Afeinman has another question.

afeinman: Since my primary reason for using native methods would be execution speed, I was wondering what the overhead for calling native functions from Java code is. Also, what is the performance hit like for diving back into the JVM?

SPK-Sheng: The overhead of calling native functions from Java is comparable to calling a normal Java method. There is a slight overhead because the VM needs to register all objects passed to native code so that the garbage collector can keep track of them. Similarly, the major overhead of calling back from C to Java is also in argument marshaling. The overhead is not significant. From a Java programmer's point of view, you need not worry about the overhead of calling native methods--especially since you must be calling native methods to accomplish certain pieces of work that will overshadow the interface overhead. As another indication of the low overhead of native method calls, all JDK built-in features must be implemented using native methods.

MDR-nancy: Here's another question from jdnbor.

jdnbor: I am building a Java setup program for installing Java applications. Pre-setup activities (finding available disk space, memory etc.) and Post-setup activities (editing config files, updating Registry etc.) are currently platform-dependent and therefore not 100% Java. However, I see the need for a platform-dependent System interface, (extension of the System properties) so that all install-related activities can be done in 100% Java. I have some suggestions/requirements on what's needed. Ultimately it will mean that these need to be integrated into the platform-dependent part of the VM by JavaSoft or licensees. How do I submit these to JavaSoft ?

SPK-Sheng: Go ahead and submit a new feature request. You can do that through the normal channel where bugs are reported. Just specify that it is a "RFE."

MDR-nancy: We are running out of time. Sheng, do you have any final comments?

SPK-Sheng: There will be an article coming out on the JDC on the topic of JNI. Also, our public web site now has a "JNI Tips" page. We will frequently update that page to address any problems programmers run into.

MDR-nancy: Thank you, Sheng, for a very informative and detailed discussion. I hope all of you enjoyed the forum. Thanks and see you next week.

SPK-Sheng: Thanks for the excellent questions and comments.

MDR-nancy: Bye.

Last moderator (me) signing off. The forum is now unmoderated.

¹ As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.