[Top][All Lists]

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

Re: Regarding the JAVA primary

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

Hi Steffen,

On 4/19/2010 1:22 PM, Steffen Dettmer wrote:
On Mon, Apr 19, 2010 at 8:25 PM, John Calcote<address@hidden>  wrote:
Builds in the Java world generally specify source files found
within a subtree using a globbing mechanism, with optionally
specified inclusions and exclusions.
Yes, they do. BTW, does anyone know why?

With some sarcasm someone could tell that it is done in this way
because with Java you need to make heaps of files (e.g. one for
every public exception), but maybe it has a good reason?

We use some very old and surely bad custom automake rules to
compile java sources. Ages ago we also had some wildcard (`find')
rules (inspired by ant assuming `this would be the good way to
go'). Those rules collected the files, but we changed them to use
a list of file names, which seemed much cleaner and solved some
issues (which of course could had been solved in other ways,

Actually, the only thing bad about the current JAVA primary make rules is that the command line length may easily be exceeded with very large file sets (in fact, with hundreds of files, it surely will be exceeded on some platforms). But this problem can easily be fixed by dumping all of the source files into a temporary text file (filename), and then by using @filename on the javac command line.

One motivation for this change was that our make rules that
generated the exception source code files (many differing more or
less just in the name and some `String name ...') and people
forgot to add the files, so if existing for them they had been
built but not for others where the files were not updated (and
the new gensrc files were missing). This resulted in an
incomplete jar file and unfortunately when using this jar a
compilation error was flagged out in the wrong package... unit
tests did not helped because of course also missing in the
incomplete jars (and the make check scheme we used also used a
wildcard approach to collect the unit tests to be executed).
Strange things happend when switching between branches (where
typically the number and kind of exceptions changed etc).

Yes, Java does promote the use of many source files - not necessarily a bad thing, as this could be seen to promote modular design, if used correctly and wisely. I tend to use static inner classes to keep relevant things together and to reduce the number of source files. The nice thing about this approach is that it's generally fairly easy to see where a class should be defined at the outer scope (and thus in its own source file), or within another class.

I disliked that when by some problem almost all sources would get
lost in a sandbox (e.g. if switching to a bad / incomplete tag),
make (and even make check!) succeeded.

On `tree conflicts' (one changed a file, another moved it) it
could even happen to have two times the same functionality in a

To build a list of files why not open in $EDITOR,
like vim or emacs, and insert the file list here (in vim, you may
start a line `java_source = \' and on the next blank line use
`!!find . -name "*.java" -exec echo "{}" "\\" ";"'
which works except for the last file, which ends with a `\'.). No
need to make this at make run time, or is there any?

By this, cvs diff (or whichever SCM tool is used) easily shows
the included files which is easier to review I think.

Using wildcards IMHO means to logically `include' the directory
contents to the Makefile. I think you cannot even use it as
dependency (and thus I'd guess the jars would be resigned on each
make run, even if no file changed?).

What is the advantage of using find magic and make time?

How do you handle your files?
How are you safe to get old generated files out the jar (if
removed from gensrc, they still are in builddir and the make
clean rule may not even take it any longer - how to notice?).

I'm afraid the find/wildcard approach only works for simple
builds - but those could also be done by ant I think...

All very good points - and all issues that Automake has been designed to overcome. Many folks don't like the requirement that all source files must be specified statically in I'm not one of these people. I tend to agree with you. For Java, I think it's a matter of developer convenience that sources in a tree are specified with a globbing pattern. It's not just that there are a lot of files, but also that they tend to be spread around the source tree because they belong to various packages that are defined by their location within the source tree.

I can certainly see how we may want to stick with the Automake "static source file specification" rules for the reasons you point out. In this case, it becomes more of an evangelistic documentation issue. :) That is, we might be wise to add a chapter to the Automake manual describing the value that comes from Automake's position in this matter. Heaven knows, we've answered the question on the mailing list more than enough times!


reply via email to

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