About mod_gcj

mod_gcj is an attempt to put a new twist on Java Web development. Setting up Apache with servlet engines has been a cumbersome task for many years. Still today, it isn't very easy to set up the Apache Foundations's own Tomcat servlet container with Apache.

Also, traditional servlet containers do not feel very well integrated with Apache or the rest of the OS platform. Of course, this kind of non-integration is part of Java's culture. One could even say it is one of Java's pillars. But is it always a good thing for server applications?

In contrast, the GCC compiler suite treats Java as just another language that is compiled down to native code. Static compilation obviously is a nice fit for server applications, where code can immediately optimized for the platform without going through the intermediate bytecode level and than compiling the code at runtime.

Another benefit is that Java code compiled with GCJ can be easily linked with other native resources and thus becomes much less isolated than Java traditionally is, and more of an equal citizen of the platform it runs on. GCJ provides its own interface for coupling Java code with C++ called CNI. In contrast to JNI, CNI is very sleek, performs well and is suiteble for use by ordinary people.

To summarize, mod_gcj aims to provide a way to serve dynamic Java Web content that is closer to the Apache Httpd and the platform it runs on.

Design Overview

The original plan for mod_gcj was to embed the libgcj runtime directly into the Apache processes, mucht like mod_perl does. Unfortunately, there was some clash between the traditional processing models with Java using threading and Apache using forking on Unix. As a result of this, mod_gcj is run in a a separate process that is forked from Apache and hosts its multithreaded libgcj runtime.

The GCJ server process is created by forking when the module is first activated, and then exec()ing an external program called mod-gcj-server located in the apache bin directory. The reason to put the GCJ server code into a separate executable is so that we can implement the module in plain C rather than C++ and get rid of any libgcj dependencies in the module itself.

The Apache module itself is written in C, while the GCJ server consists of some C++, mostly for Unix domain socket communication, and is otherwise written in Java. It is multithreaded using GCJ java threads.

The fact that the GCJ server is executing in a separate process is largely invisible to users/administrators:

• The server is started/restarted/stopped automatically by the Apache module

• All configuration is done from Apache configuration files using standard Apache directives

• Java handlers can decide to decline a request, allowing it to be handled by other Apache modules.

In the future it may be possible to interact with other Apache modules from Java code, implement Apache hooks in Java etc.

Credits

After coming up with this design blueprint, I found out that mod_mono uses pretty much the same approach to implement ASP.NET for Apache. Thanks go to the authors of mod_mono, Daniel Lopez Ridruejo and Gonzalo Paniagua Javuer, for allowing me to use their work to get started with mod_gcj. This has allowed me to get some useful code much faster than it would have been otherwise.