Java support

[tsuna]

Hi all,
whether I like it or not, it so happens that I have a Java project I'm
trying to package properly, and I'm trying to use autoconf/automake
for maximum portability and ease of integration with various distros
(since most of them have tools to automagically build packages on
properly autotoolized projects), not to mention all the usual benefits
that the autotools provide out of the box.

I'm aware of http://sources.redhat.com/automake/automake.html#Java-Support
(support via GCJ) but that's not what I want.  Most of the Java people
don't use GCJ, they use Sun's JDK.  Somewhat confusingly perhaps, that
section of the documentation doesn't refer to
http://sources.redhat.com/automake/automake.html#Java which seems to
be closer to what I want.  It's not clear from that part of the
documentation how to get a .jar and have it installed etc.  I read the
code in lib/am/java.am and it seems all it does is to compile all the
.java files into .class files and install the .class files.  The good
thing about this is that it's compiling all the .java files at once
(and not one-by-one like we do with C/C++ files), the bad thing is
that it has no facility to produce and install a .jar file that
contains all the .class files, and it only supports one _JAVA target
per Makefile.am.

I noticed there's a branch called "java-work", however it's not clear
to me what improvements it has, and its lib/am/java.am seems pretty
much identical.

One of the problems noted in the manual and in Automake's code is that
a single .java files doesn't predictably translate into a .class file.
 And there's no equivalent to gcc -M in the Java world.  "Foo.java" is
pretty much guaranteed to produce "Foo.class", but frequently there
will be other class files of the form "Foo$Something.class" produced
(this is because the nested class "Something" in the class "Foo" is
compiled into its own file).  Right now in my project I build pretty
much everything with custom rules (even though I just switched from
plain Make to Automake) and the approach I've used to work around this
problem is to assume that "Foo.java" will produce "Foo*.class".  I
don't know if Automake could use this approach too, since there are
cases where this will glob unrelated files, but it's working like a
charm in my project.  Ideally we should look for "Foo.class" and,
maybe, "Foo$*.class", however the `maybe' part is annoying because if
the globbing pattern doesn't match anything, it'll stay as is or,
worse, produce an error with some shells (e.g. zsh with certain
options).

My question now boils down to this:
Has anyone already got some thoughts on how to make Automake play well
with Java projects or what kind of workarounds can I use to leverage
as much of Automake as possible while still building my Java stuff the
way I want it?

Alternate question: if Java was a brand new language Automake had
never heard of, how would I build my project with Automake without
doing what I'm doing now where I have custom rules for everything and
I need to hook myself into install- and dist-hooks to Do The Right
Thing?  Like isn't it possible to have a bin_PROGRAMS = foo.jar and
foo_jar_SOURCES = main.java and then tell automake how to transform a
.java into a .class and then how to turn all the .class into a .jar?
It seems that when I try this, Automake dies with "Java source seen
but `GCJ' is undefined".

Thanks and sorry for the longish email.

-- 
Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com