Why Static Compilation?
Two popular approaches for compiling Java programs are Just-In-Time (JIT) compilation
(e.g. Sun Hotspot , Cacao , OpenJIT , shuJIT , vanilla Jalapeno ) and static compilation (e.g. BulletTrain , Excelsior JET , GCJ , IBM VisualAge for Java , JOVE ).
It would be wrong to say one approach is definitely better than the other, since
they are suited for different situations .
In fact, current research on
``quasi-static compilation'' 
shows that combining these two may yield excellent results.
In practice, static Java compilers are sometimes desirable over
JIT compilers because they have many
- Static compilation yields more robust deployed applications.
On the one hand,
a deployment JIT may be different from the development JIT, which
can cause problems due to even slight differences in the virtual
machine or library code. With static compilation, programs are
compiled into native code allowing the developer to test exactly what is deployed.
On the other hand, compilers have bugs. Crashes caused by static
compiler bugs sometimes happen at compile time (unless the bug is
the kind that generates bad code silently), while bugs in the JIT
may cause crashes at program execution time, and some of them may
only surface after a portion of the program has been executed many times.
Moreover, if the program crashes due to a bug in either the compiler
or the program itself, statically compiled code is much easier to debug
because the run-time trace is more predictable.
- Static compilation provides better intellectual property protection.
Native code is much harder to reverse-engineer than Java bytecode.
- Static Java compilers can perform resource intensive optimization
before the execution of the program. In contrast, JIT compilers must
perform analysis at execution time, thus are limited to simple
optimizations that can be done without a large impact on the combined
compile and execute time.
- Static compilation achieves greatly reduced start-up cost, reduced
memory usage, automatic sharing of code by the OS between applications,
and easier linking with native code.
- Last but not least, static compilation is better suited for code
certification than JIT compilation. It is significantly easier to achieve
higher safety assurance by removing the compiler from the trusted computing
base. There has been a lot of work done in this
area [23,21,19] which mostly focuses on
Regardless of the above advantages, there is an ongoing debate
in the Java community on whether statically compiled implementations
can meet the Java specification on dynamic features such as
binary compatibility. Our paper presents a scheme that accommodates
the seemingly contradictory goal of full Java compliance and
static compilation, thus showing that binary compatibility can indeed
be supported using static compilers. Following the inspiration of
``quasi-static compilation'' , this technique
can also be used together with other JIT compilation techniques to
achieve an optimal balance point between static and dynamic compilation.
Thus we believe this result is of interest to the general audience in
the JVM community.