[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Regarding the JAVA primary
Regarding the JAVA primary
Mon, 19 Apr 2010 12:25:22 -0600
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:184.108.40.206) Gecko/20100317 Thunderbird/3.0.4
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 Makefile.am -- 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.
- Regarding the JAVA primary,
John Calcote <=