Chapter 8. JNI You cannot dedicate a book
Tuesday, October 31st, 2006Chapter 8. JNI You cannot dedicate a book to Java performance without addressing the issue of Java Native Interface (JNI.) After all, JNI is perceived by many to be the performance silver bullet when all else fails. Imagine working on a performance-challenged Java code, trying all the ideas set forth in earlier chapters and still falling short in achieving efficiency. You may be tempted, in desperation, to turn to JNI as a last resort. There are actually three popular scenarios for the use of native methods: . You may have a complex, pre-existing software written in C/C++ and the conversion of this code to Java is not a practical option for some reason. You can hook this software into your Java code via JNI. In this case, JNI bails you out of a costly porting effort. . You may need computational results that are simply not available in the Java environment and that necessitate the use of a system call. There are many such examples in the JDK that you may not be aware of. For example, System.currentTimeMillis() retrieves a timestamp from the underlying physical machine. . You may want to speed up a slow computation, and you think JNI will help you via C/C++ execution. In this chapter we will discuss the last (third) item only, as it is rooted in performance considerations that are up for debate. There’s a popular misperception that JNI is always a performance winner. The reality is not that simple. Page 176
Note: If you are looking for cheap and inexpensive provider to host and run your tomcat application check Actions tomcat hosting services