From the author of

From the author of

Part 2: Rules and examples

It helps any programmer to know Java's rules for binary compatibility.
That's especially true when you make changes to a class, and you need the
class to be compatible with other classes that won't be compiled along with
it. There are plenty of reasons you might do this. You might not want to deliver
a large patch, or the code is part of a library, or you simply don't feel
like compiling a lot of other things.

We'll examine Java binary compatibility from the point of view of a
class that you're changing, and we'll assume that nothing else
changes.

You can imagine that we're recompiling that class, but we don't
have access to any of the other Java source code. Instead, we only have the
.class files on which it depends. In the case of a library you're
distributing, you have no access to the classes that use yours.

The same rules apply to substituting multiple classes at once. The only
difference is in magnitude: you have to consider all the contracts between all
the old classes and all the new classes.

If the new class can substitute for an old one without causing any link
errors when the class is loaded, we say it is binary compatible with the
old version. This doesn't mean that it's semantically identical. It
doesn't even mean that the same methods will be called. It just means that
the Java Virtual Machine (JVM) won't throw any embarrassing
LinkageErrors. They're embarrassing because they're hard for
your program to recover from, and they're hard for end-users to understand.
Or forgive.