Java Reference
In-Depth Information
9.2
T
HE
N
EED FOR A
D
IFFERENT
B
UILD
T
OOL
James Duncan Davidson had a problem. Perhaps you've had this problem, too.
It has to do with the building of software—compiling, copying, and otherwise
modifying files to get all the pieces in all the right places for running a collection
of programs.
There are a number of ways to automate the building of software. You can
script the compilation using shell scripts or batch jobs. That works fine, but
there are two problems with that solution. First, scripts are generally not
portable across very different operating systems. That's a serious problem for a
language like Java, which is intended to be portable across operating systems.
Second, it is difficult if not impossible, using scripting languages, to prevent
wasted compiles; the checking and comparing of date stamps on source and
object files makes scripts large and difficult to maintain.
Very well, we hear you say. There's
make
. The
make
program has been
around for a long time. It is available on many operating systems. It handles
the conditional compilation of files very well. It has been around for centuries
(it seems). It is well known and widely used. All of this is true, but even this
venerable tool falls a bit short in the Java world. First of all, although makefiles
are generally far more portable than other scripts, there are still considerable
variations in details, and
make
does nothing to mask the differences in file,
path, and disk designations that exist across operating systems. Moreover, both
make
and scripts suffer from a more basic problem. Although Java programs
can execute reasonably quickly, the overhead of starting a JVM and tearing it
down again is considerable. Since
javac
is written in Java, each time it is in-
voked to compile a source file (one file at a time is the
make
way) this setup
and teardown time cost is paid.
But, we once more hear you protest, you can just use
javac
on the entire
project! Doesn't it build everything that needs to be built? In the simplest case,
yes, it does. But as soon as you share code between projects, or use RMI which
requires execution of the
rmic
compiler, or use EJBs, or link in native methods,
then
javac
's dependency resolution just will not work.
Luckily, James Duncan Davidson had this problem. And luckily it really
bothered him. And even more luckily for us all, he decided to share his solution.
