Subject: bug#9088: Java, JARS primary?

From: Michael Zucchi <[email-masked]>
Date: Wed, 15 May 2013 21:22:48 +0930

On 14/05/13 03:47, Stefano Lattarini wrote:

> Instead, let's start implementing something *correct*, in line with
> the Java philosophy, and with a clean API.  We'll think about enhancing
> it when (and if!) the need arise.

Seems the way to go.

On that, here are a few more thoughts on java's specific way of doing
things ...

files vs dirs
--------------

java projects/build systems tend to have a fairly basic mechanism to
define the source tree(s) which would be nice to emulate, but may not
fit well with the portability requirements of automake.

They simply define the root directory and let the build system do the rest.

Not necessary but would be nice.  Or put another way it would basically
suck if it required every source file to be listed explicitly and auto*
having to be re-run every time one is added.  In a GNU makefile I can
just use $(shell find) (or other fancier stuff), but for automake?

source vs data
--------------

A source tree can also include non-source data which is copied into the
jar file verbatim at the same relative path location.  At least this is
how ant does it and given the way these resources are resolved at
runtime makes the most sense.

Again I think this needs to be specified by root directory not file.  It
could just hang off the _SOURCES or use _RESOURCES.

makefile location
-----------------

C projects often have a make file per directory, java has the build
script at the top-level at least, outside of the source trees.

This is desirable.

For the compiled code this is simple enough since the makefile will
compile every file every time and the compiler will dump the class files
where it's told.

For the resource files the Makefile needs to resolve the resource root,
and strip it out of the names used for the dependencies.  So either it
needs a (set of) explicit resource_root, resource_root_files variables,
or it just needs to be defined as the root dir and handled either in the
makefile fragment or in automake.in.

annotation processors
---------------------

I think these can be handled by using _JAVACFLAGS or something similar.
 They can generate source for new classes at compile time, but this is
all handled by javac in separate locations so make doesn't need to know
about it.

javadoc, jni, check/test, etc
------------------------

Some built-in support would be good.  javadoc is easy, check/test should
run junit tests I guess although i'm not too familiar with junit, jni
will need some thought but should be limited in scope (support for javah
basically, maybe not enough need to include it in automake so long as
the dev can depend on the jar).

first cut
---------

I've attached a pretty nasty bit of unportable makefile which attempts
some of the above to see how it might be done.  Even with gnu make stuff
it still needs some support from automake.in to handle multiple resource
directories, and it doesn't handle everything quite properly.

The build steps from this are simple:

$ rm foo_jar.stamp ; make -f Auto.mak
javac -cp lib/jjmpeg.jar:lib/test.jar -sourcepath src -d
build/classes/foo_jar src/z/util/d.java src/z/util/c.java src/z/a.java
src/z/b.java
touch foo_jar.stamp
jar cf foo.jar -C build/classes/foo_jar . \
        -C ./src ./z/util/util-names.txt \
        -C ./res ./foo.txt
$

Regards,
 Michael