|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 5 of 6
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.
The class verifier contributes to the JVM's security model by ensuring class files loaded from untrusted sources are safe for the JVM to use. Rather than crashing upon encountering an improperly formed class file, the JVM's class verifier rejects the malformed class file and throws an exception. The class verifier catches problems caused by buggy compilers, malicious crackers, or innocent binary incompatibility.