bug#9088: Java, JARS primary?

[Stefano Lattarini]

On 05/12/2013 06:29 AM, Michael Zucchi wrote:
> Hi again,
> 
> I (mostly) just have an observation to add to the bug tracker discussion
> on the dependency generation.
> 
> Using $? will not suffice as a dependency check, as it's trivially easy
> to create an example which will compile ok after a change but create a
> broken jar. e.g. add a new abstract method to an abstract class but
> forget to fix all sub-classes.
>
I don't really follow here, sorry (likely because I know almost nothing
about Java).  Do you mean that, if you have a bunch of .java files that
get compiled into a single jar, and you change just one of these files,
you also need to recompile all the other ones in order not to risk ending
up with a broken and/or inconsistent jar?  If it is so, that's awful :-(

> So without compiler support for dependency generation I think the only
> practical solution will be to build all files every time.  Even the
> sub-directory holding the classes will probably need to be wiped away
> otherwise the jar could contain extraneous classes no longer generated
> from the corresponding source which would probably not be a good thing.
>
Couldn't we put the *.class files obtained compiling a foo.java file
into a (say) 'foo.d' directory, and remove & rebuild only that directory
whenever foo.java changes?

> I have had a bit of a look at automake.in and some of the .am files - it
> seems to me it would not be any use using the existing in built language
> code as that is designed for 1:1 source:object compilation.
>
Maybe we can steal some code from the existing _JAVA primary though, were
that makes sense?

> But before I get too bogged down in that I think I will first try to
> create a simple Makefile with the required features for discussion, and
> then worry about how to generate it.
>
This is the sanest approach, yes.  You might also write some tests on the
expected behaviours of this Makefile, and we could later re-use them in
our testsuite.

> Most of it should be straightforward apart from deciding on conventions.
> 
> Regards,
>  Michael
> 

Thanks,
  Stefano