Can the bytecode of a class change if a parent class/interface changes?

Question

I'm trying to determine if I need to recompile some jars in our build chain, if I have for example the following structure, jar 1 compiles when its' source changes and jar 2 compiles when its' source changes or when jar 1 has recompiled.

jar 1:

public class Foo /* impl*/

jar 2:

public class Bar extends Foo /*impl*/

Assuming the contract between the 2 classes doesn't change, ie. an abstract method is added or a method is added to an interface, etc.

Do I need to recompile jar 2? ie. if some changes are made to a private method within Foo would Bar need to be recompiled?

I tried testing this by comparing the bytecode of two classes after changing a bunch in one and as expected it did not change. My coworkers however insist that they have encountered situations where even though the contract was unchanged they had to recompile everything for it to work, however they can't remember what the reason was... So the burden of proof is on me to show that that should not be necessary. Is there a case where making a change to a superclass will require the subclass to be recompiled even though the interface between the two has remained the same?

Answer 1

Let's say Foo is released by an open source organization; and there are thousands of subclasses of Foo implemented by various companies.

Now if some changes are made to Foo, and a new version is released in binary form, should all companies recompile their code? Of course not. (well, we do recompile all code all the time, but it is not required - the new jar of Foo can be simply dropped in without causing any problems)

This is the issue of binary compatibility, and you can check the spec to make sure that a change to Foo is safe. see http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html