dingbat@codesmiths.com wrote:

As far as I know, the contents of one classfile -- as produced by the
compiler -- are independent of the source (or classfile) for any other class,
with the following exceptions:

Obviously the faked-up relationship between inner and outer classes is tighter,
but that shouldn't be an issue here.

Numeric, boolean, and String fields (including non-static fields) which are
declared to be final, and initialised to a compile-time constant, are inlined
whereever they are referred to in any [other] class.  Hence, if you change the
values, then you must recompile the classes which use them.

There is only one circumstance where changes can propogate transitively --
that's when one class uses another class's constants to define its own.  E.g:
   public class A {  public static int X = 1; }
   public class B {  public static int Y = A.Y * 10; }
   public class C {  public static int Z = B.X * 10; }
In the above case, changing A.X means that classes B /and/ C have be
recompiled.

The Java compiler does a great deal of early binding -- it checks that methods
and fields exist in other classes (and that they are accessible, etc) before it
will let you use them.  So, clearly, removing a member could cause another
class to become uncompilable.  (Come to that, so can removing a class ;-)
Changing the class tree in a way that changes a class's total set of methods
and fields (including inherited ones) counts as adding or removing for these
purposes.

A more subtle, but related, point is that if you add or remove overloaded
methods, then the compiler might change it's mind about how to resolve an
overloaded method call.  E.g. if you have in V1 of your class:
   public class XYZ
   {
       public void aMethod(int i) { .... }
   }
and a caller in another class:
   xyz.aMethod('a');
then the compiler will statically resolve that call to invoke the (possibly
overriden) aMethod(int).  If you now add an overload to XYZ
   public class XYZ
   {
       public void aMethod(int i) { .... }
       public void aMethod(char c) { .... }
   }
and recompile /without/ recompiling the caller, then it will still call
aMethod(int).  If you now recompile the caller, then the static part of method
resolution will now see the new method as a better match for the parameter, so
it will generate code to invoke aMethod(char) instead.

============

Some examples of changes which do not propogate to other classfiles:

Changes to the bodies of methods in one class do not result in changes to any
other classfile.  Adding or removing members (fields, methods, nested classes)
does not result in changes to any other classfile unless it refers to those
specific members.  Re-ordering members does not result in changes to any other
classfile even if it /does/ use those members.

An example of where a fairly drastic change to one class doesn't cause changes
to another class's compiled form.  If we start with XYZ in its first form
above, and compile
   xyz.aMethod(0);
against it, then we'll get a certain compiled form for the caller.  If we now
refactor XYZ into
   class ABC
   {
       public void aMethod(int i) { .... }
   }
   public class XYZ
   extends ABC
   {
   }
and recompile the caller, then we'll get exactly the same compiled form as
before.

   -- chris