[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#9088: Java, JARS primary?

From: Stefano Lattarini
Subject: Re: bug#9088: Java, JARS primary?
Date: Sun, 12 May 2013 18:58:29 +0200

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 file
into a (say) 'foo.d' directory, and remove & rebuild only that directory
whenever changes?

> I have had a bit of a look at 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]