Advertisement

Incompatible changes: An example
As an example of incompatible changes, imagine you compiled class Volcano (from the above example) with a Java compiler. Because a method in Volcano invokes a method in another class named Lava, the Java compiler would look for a class file or a source file for class Lava to make sure there was a method in Lava with the appropriate name, return type, and number and types of arguments. If the compiler couldn't find any Lava class, or if it encountered a Lava class that didn't contain the desired method, the compiler would generate an error and would not create a class file for Volcano. Otherwise, the Java compiler would produce a class file for Volcano that is compatible with the class file for Lava. In this case, the Java compiler refused to generate a class file for Volcano that wasn't already compatible with class Lava.

The converse, however, is not necessarily true. The Java compiler conceivably could generate a class file for Lava that isn't compatible with Volcano. If the Lava class doesn't refer to Volcano, you could potentially change the name of the method in Lava that Volcano invokes, and then recompile only Lava. If you tried to run your program using the new version of Lava, but still using the old version of Volcano, the JVM would, as a result of phase two class file verification, throw a "no such method" error when Volcano attempted to invoke the now non-existent method in Lava.

In this case, the change to class Lava broke binary compatibility with the pre-existing class file for Volcano. In practice, this situation may arise when you update a library you have been using, and your existing code isn't compatible with the new version of the library. To make it easier to alter the code for libraries, the Java programming language was designed to allow you to change a class in many ways that don't require recompilation of classes that depend on the changed class. The changes you are allowed to make are governed by the "rules of binary compatibility," which are listed in the Java Language Specification (see the Resources section for a link to this spec). These rules clearly define what can be changed, added, or deleted in a class without breaking binary compatibility with pre-existing class files that depend on the changed class.

For example, it is always a binary compatible change to add a new method to a class but never to delete a method that other classes may be using. So in the case of Lava, you violated the rules of binary compatibility when you changed the name of the method used by Volcano, because, in effect, you deleted the old method and added a new. If you had, instead, added the new method and then rewritten the old method so it calls the new, that change would have been binary compatible with any pre-existing class file that already used Lava, including Volcano.