Stefano Lattarini <stefano.lattar...@gmail.com> writes: > 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 :-( Think of it like changing a header file in C to change the definition of a struct. If you don't recompile all of the C source that references that struct, you get broken code. The same thing is true in Java, except that Java doesn't have separate files for interfaces versus implementations (or at least doesn't mandate it; that's a coding style that some people use and other people don't). Java development environments like Eclipse figure out the necessary dependencies and know what *.java files need to be recompiled to pick up changes (and detect errors). If one is using a command-line compiler that can't generate similar sorts of dependency information, it's usually best to just rebuild all the *.java files that make up a JAR if any of them have changed, to ensure that no errors have been introduced and no internal APIs have changed. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>