Skip to main content

Tomcat goes Native

Posted by opinali on October 3, 2005 at 8:53 AM PDT

Check Tomcat 5.5.12 or later. When you install these new builds, the installer (at least on Windows) offers to download a native code library that Tomcat will use to optimize some performance-critical tasks like connection handling, file I/O and SSL encryption. This feature is documented here. It looks really cool because it relies on the APR -- Apache Portable Runtime, parte of the Apache HTTP server -- and OpenSSL. Both are very robust, secure and efficient pieces of native code. And of course, these components are also open source, and very multiplatform (I guess that Apache HTTPD/APR and OpenSSL should support more platforms than J2SE does). So I don't bother than Tomcat is less "pure" now (do you?). If you don't want to mess with the additional setup procedures or don't trust this native code, or even if it's not available for your platform (the Tomcat/APR connector is still in alpha stage so it's posible that they don't have pre-built binaries for everybody right now) -- you don't have to use it, it's an optional component.

There are other Java programs and libraries that rely on native libs, but this is indeed very rare in such "standard" components like Tomcat, that is not published by Sun and the JCP but it's very close to such official status. Tomcat is the RI for the Servlets and JSP JSRs, and it's the Web container inside Sun's J2EE server, as well as JBoss and others. Because Tomcat is so popular -- I don't know any numbers, but I guess it should be the #1 Java Web container either directly or indirectly as piece of larger J2EE products -- this native-code support will eventually propagate to the other servers, products and apps that rely on Tomcat.

And of course, there is also Grizzly, presented in JavaOne 2005; this is an effort to optimize Tomcat with java.nio, part of Sun's GlassFish project. I wonder whether Grizzly and Tomcat's native connector (which also uses java.nio) are competing or complementary projects? In either case, none of these projects have yet reached production quality, so we'll have to wait for serious benchmarking.

The Java VM technology is wonderful, it can very often compensate the overheads imposed by Java's high-level design and beat native compilers, thanks to the opportunities of dynamic optimizations. But there are a few areas where native code is still better, like strong interaction with the OS (e.g. for front-end TCP/IP handling), and "extreme" algorithms like encryption that depend on such tricks as manual vectorization/SIMD (very often you gotta get down to Assembly, because not even stock C compilers are good enough on these). Now that java.nio and DirectBuffers solved most of the Java/native overhead issues, the biggest reasons to not use more native code are portability and robustness. But if you're not writing new libs, just using stuff like the APR that's already mature and multiplatform, I think there's no conflict with the "Run Everywhere" tenet.