bug#9088: Java support

[tsuna]

On Fri, Jul 15, 2011 at 1:58 AM, Stefano Lattarini
<address@hidden> wrote:
> You're right; the documentation on Java support should be definitely
> be improved (especially making better distinction between usual bytecode
> compilation with javac and "native/binary compilation" with gcj).

I just sent a trivial patch to automake-patches (Message-Id:
<address@hidden>) to add
cross-references between the two sections.  I was rather confused when
I realized there were 2 different sections about Java in the manual.
Eventually these 2 sections should be merged, but for now the
cross-references will help remove some of the confusion.

> I'd rather deprecate the JAVA primary, and then introduce a new `JARS'
> primary, to be used e.g. as follows:
>
>  jar_JARS = foo.jar
>  zardoz_JARS = bar.jar
>  foo_jar_SOURCES = all.java foo.java
>  bar_jar_SOURCES = all.java bar.java
>  bar_jar_JAVACFLAGS = -nowarn
>  bar_jar_JARFLAGS = -J-Xmx48M
>
> This should cause the following behaviour:
>
>  1. javac will be called (with the `-d' option), to generate .class files
>    from all.java and foo.java, and put them into a "private" directory
>    `.classes/foo_jar/';
>
>  2. similarly, javac will be called (this time also with the `-nowarn'
>    option) to generate .class files from all.java and bar.java, placing
>    them into the directory `.classes/bar_jar/';
>
>  3. jar will be called to build `foo.jar' from all the .class files found
>    in .classes/foo_jar/;
>
>  4. similarly, jar will be called (this time with the `-J-Xmx48M' option)
>    to build `bar.jar' from all the .class files in .classes/foo_jar/;
>
>  5. "make mostlyclean" will remove the `.classes' directory;
>
>  6. "make clean" will also remove foo.jar and bar.jar;
>
>  7. "make install" will install foo.jar in $(jardir) (which we could make
>    default to `$(datadir)/jar') and bar.jar in $(zardozdir) (which we
>    expect to be user-defined).

This sounds excellent.

> As my java foo is pretty weak, I'm not sure how to handle jar manifests,
> jar entry points, or other jar/javac subtleties and advanced features.
> Suggestions welcome.

You can create the manifest manually fairly easily.  Here's an example
in the project I'm in the process of autotoolizing:
https://github.com/stumbleupon/opentsdb/blob/6059488f38fc8a51d426d6972eee6fdd1033d851/Makefile#L207

It doesn't define an entry point, but you get the idea.  The thing is,
manifests can (and frequently do) contain arbitrary fields, some of
which are standard (or de facto standards), some of which are not.  So
I'm thinking the best thing would be to let people create their own
manifest if they wish to, and give them an easy way to specify what
file should be used as the manifest.  If they don't specify anything,
then Automake would add rules to generate a fairly arbitrary manifest.

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