Re: Regarding the JAVA primary

[John Calcote]

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,
> too).
>    

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
> jar...
>
> To build a list of files why not open Makefile.am 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 java.in 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 Makefile.am. 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!

John