If the parent class / interface changes, will the bytecode of the class change?

I am trying to determine whether some jars need to be recompiled in the build chain. If I have the following structure, jar 1 will be compiled when its source changes, and jar 2 will be compiled when its source changes or jar 1 is recompiled

Can 1:

public class Foo /* impl*/

Jar 2:

public class Bar extends Foo /*impl*/

Assume that the contract between the two classes does not change, i.e Add abstract methods or add methods to interfaces, etc

Do I need to recompile jar 2? Namely If you make some changes to the private methods in foo, does bar need to be recompiled?

I tried to test this by comparing the bytecodes of two classes, changing a heap in one and it didn't change as expected However, my colleagues insist that they have encountered situations where they have to recompile everything to work even if the contract has not been changed, but they don't remember the reason... So the burden of proof on me proves that this should not be necessary Is there a case where making changes to a superclass will require recompiling subclasses, even if the interface between the two remains the same?

Solution

Suppose foo is published by an open source organization; And there are thousands of foo subclasses implemented by various companies

Now, if you make some changes to Foo and release a new version in binary form, should all companies recompile their code? Of course not (well, we've been recompiling all the code, but it's not necessary - the new foo can be simply put in without causing any problems)

This is a binary compatibility issue. You can check the specification to ensure that changes to foo are safe see http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html