[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Regarding the JAVA primary

From: John Calcote
Subject: Regarding the JAVA primary
Date: Mon, 19 Apr 2010 12:25:22 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100317 Thunderbird/3.0.4

Hi Ralf,

I've been thinking a lot about the JAVA primary lately. It turns out that Automake's handling of Java sources is pretty efficient. Experiments indicate that building ~500 Java source files in a single command takes about 15 seconds on a 1.8 GHz CPU with 512 MB RAM. That same set of 500 sources, built individually can take upwards of 500 seconds - a 40 times increase in compile time. (GNU Make, O'Reilly)

In other words, it's simply better to not manage individual source/object dependencies in Java. You win the battle, so to speak -- but you lose the war.

Since the current implementation of the JAVA primary is not managing individual source/object dependencies (something that's difficult to do anyway because of inner and anonymous class definitions), would it not be prudent to remove the restriction regarding needing to specify all source files individually in -- at least for the JAVA primary?

Builds in the Java world generally specify source files found within a subtree using a globbing mechanism, with optionally specified inclusions and exclusions. And the layout of that subtree defines the packages to which classes belong. Would it not be fair to say that all files found matching the source specification within a specified subtree are distributed within the directory layout to which they belong? In other words, distribution (for Java sources only) would include the same set of files specified in the Java source globbing pattern. Here's an example:

sources = src/**/*.java
exclude = src/examples/*.java

Distributed Java sources would include everything defined by /sources/. Excluded files would be excluded from the build, but not from distribution.

I'm not stealing this concept entirely from ant. Most of the Java IDE's (NetBeans, IntelliJ, Eclipse, etc) also use almost the same mechanism for specifying sources belonging to a particular build.

I recognize that this is a significant deviation from existing Autotools methodology, but I'm not sure we can make any real forward progress in Autotools Java builds without making a few such concessions.

A problem I foresee is providing the globbing functionality to makefile commands. We'd almost need a new auxiliary script (like install-sh) to generate lists of files from such glob specs. Not sure yet from where the primary functionality would come -- perhaps a java utility, so that the same level of portability would be available to java builds as the source that's being built. That is, if someone uses the JAVA primary, he/she can expect to be required to have additional build functionality available, in the form of a JVM and javac compiler. Just a thought.

One thing we can do at this point is to define JAR and WAR primaries that build and install (in appropriate locations), .jar and .war files. I've got a few ideas I'll try to codify and send out shortly.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]