Description

Most advice on-line about using makefiles with Java says the following:

Don't! Use Ant instead.

I disagree that a tool newer than GNU Make is necessary, and have some comments about why I don't use Ant.

Other advice, that which advocates the use of Make, often naïvely suggests something like this:

%.class: %.java
	$(JAVAC) $<

This results in many more invocations of the compiler than necessary (undermining one of the benefits of an incremental build), and potentially generates an incorrect build.

Jardeps is an attempt at incremental builds for Java projects using makefiles, and I believe that it is a better approach than using the <javac> task in Ant (prior to Java 8, or without <depend>), or a naïve rule in GNU Make.

Here's what is expected from the developer using this scheme:

• The source should be split into source trees, such that there are no dependency cycles spanning more than one tree. (Cyclic dependencies within a tree are permitted.)

• The trees which make up a jar are specified. (It is reasonable to have one tree per jar, and this is the default.)

• The root classes of each tree should be identified. These are the ones which the developer positively requires in the resultant jar.

  You have the option to compile all source files, with specific exclusions.

• Dependencies between trees should be specified manually. For example, the developer should know that tree impl depends on tree api.

Here's what the developer can expect in return:

• A built tree will only contain its root classes, plus everything in the same tree which those classes need, i.e., the implicit classes.

• A tree will only be recompiled if any of its source files changes, or the public profile of one of the trees it depends upon changes. This will allow you to make modifications on the internals of a tree without triggering a recompilation of dependent trees.

  A profile is a summary of the public aspects of the classes in a tree, automatically generated when it is compiled. You can also express dependencies on package-private (default) profiles, or even on the implementation, if necessary.

In summary, you get an incremental build at the granularity of trees (which is feasible both efficiently and correctly), rather than of classes (which is not).

The main problem with Jardeps is speed. The compiler must keep track of source files it used, and class files it generated, though the overhead for these should be low. However, it also has to perform a post-compilation analysis of the class files, which might significantly increase total processing time. Furthermore, these additional activities are bolted onto the compiler by invoking it from a Java process, which should save time by avoiding duplication of work done by invoking a separate process after the native compiler, but which could also increase overhead due to having to start a Java process just to run the compiler, an overhead which a native invocation of javac might avoid. Additionally, under Jardeps, separate trees are intentionally compiled with separate invocations of the compiler, so this overhead could be incurred several times.

I have not measured how bad this overhead is, and my Java projects are probably too small to amortize the overhead by not having to recompile everything, so if you try Jardeps on a bigger project, please let me know how well it performs. Also, Jardeps could be seen as a proof-of-concept, demonstrating that all the information required to generate rules for make can be obtained by augmenting the compiler, and so some of the speed can be recovered by augmenting the native compiler. These augmentations come in the form of some additional options. Despite my opposition to Ant, such options could also be exploited by an enhanced <javac> task.