bug#9088: Java support

[Stefano Lattarini]

On Saturday 16 July 2011, tsuna  wrote:
> 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.
>
I agree that the present situation is overly confusing; your patch offers
a small but definite improvement, so I'll apply it.  Thanks.

> Eventually these 2 sections should be merged,
>
Note sure about that, as they deal with different situations.  But maybe
they can become distinct subsections of a new single "Java support"
section (these subsections being named something on the line of "Support
for bytecode-compiled Java" and "Compiling Java to native binaries with
GCJ" -- suggestions for better titles are welcome).

> but for now the cross-references will help remove some of the confusion.
>
Agreed.

> > 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.
>
Good.  Notice however that I'm probably not going to tackle this issue
anytime soon, as I'm in the middle of my GSoC project right now (but
also notice that the present discussion is being duly registered in the
bug tracker, so we're not losing our time here).

> > 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
>
Thanks, I'll take a look at that (when the times comes to write the patch).

> 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.
> 

Regards,
  Stefano