19.5 Using Native Methods

Java Servlet Programming, 2nd Edition > 19. Odds and Ends > 19.5 Using Native Methods

< BACK

CONTINUE >

Despite Sun's push for 100% Pure Java, native code still has its place. You need native code to do things that Java (and external programs launched by Java) cannot do: locking files, accessing user IDs, accessing shared memory, sending faxes, and so on. Native code is also useful when accessing legacy data through non-Java gateways. Last, in situations in which every last bit of performance is vital, native code libraries can give a servlet a big boost.

Native code, however, should not be used except when absolutely necessary, since if the native code run by a servlet goes south, the entire server goes down with it! The security protections in Java can't protect the server from native code crashes. For this reason, it's wise not to use the native JDBC-ODBC bridge from a servlet because many ODBC drivers seem to have problems with multithreaded access. Native code also limits the platform independence of a servlet. While this may not matter for custom-built servlets tied to a particular server, it's something to remember.

How a servlet accesses native methods depends on the web server and JVM in which it's running. To take a risk and speak in broad generalities, let us say that you can pretty much expect your web server and JVM to support the standard Java Native Interface ( JNI). Using JNI is fairly involved, and even a basic introduction extends beyond the scope of this chapter.

When using JNI with servlets, remember these things:

Only the most liberal server security managers allow a servlet to execute native code.
There is a JDK 1.1.x bug that doesn't allow native code to be loaded by a class that was loaded with a custom class loader (such as the class loader that loads servlets from the default servlet directory). Servlets using native code may therefore need to reside in the server's classpath (such as server_root/classes).
The directory where the shared library (or dynamic load library or DLL) that contains the native code is placed depends on the web server and JVM. Some servers have specific locations where they look for shared libraries. If the server doesn't provide a specific shared library directory, try placing the library in a JVM-specific location such as jdk_root\bin or under jdk_root/lib (where jdk_root is the root of the JDK install), or try an operating system-specific location such as windows_root\system32 or /usr/lib.

< BACK

CONTINUE >