GNU bug report logs - #9088
Better java support with new JARS primary

Previous Next

Full log

Message #60 received at 9088 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Michael Zucchi <notzed <at> gmail.com>
Cc: 9088 <at> debbugs.gnu.org, automake <at> gnu.org
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 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.