Java Binary Compatibility Part 2
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.