Scenario C: Binary Change at Run Time

Some static compilers (e.g. BulletTrain) perform dependency analysis before executing a Java program, and attempt to recompile if inconsistency is detected. In the cases of scenarios A and B, these compilers would have refused to run Manager, or attempted to recompile it automatically. The problem is that this behavior is not only non-compliant with the binary compatibility requirements of the JLS (which intends to solve these issues without recompilation of the client classes of the changed class), but also that this dependency analysis cannot always be done statically.

A simple example which presents a challenge to the static dependency analysis scheme is reflection. Using reflection, a program can load arbitrary class files which are not known at compile time. This means that the static analysis may not work out all the dependencies. Even if reflection is not a concern, binary changes may occur at run time after some classes are already loaded and executed. In these cases, recompilation is not possible. Here we use another binary-compatible change, namely the insertion of a new class into the class hierarchy, to demonstrate the problem.

public class OOProgrammer
     extends Programmer { // New Class!
  void drink() { ... };
}
public class JavaProgrammer
     extends OOProgrammer{ // New Hierarchy!
  void eat  () { ... };
  void hack () { ... };
  void study() { ... };
}

Based on the original program, before we make any changes, suppose class Manager (but not JavaProgrammer) is already loaded and being executed. During the execution of the first line of main, we insert a new class OOProgrammer between Programmer and JavaProgrammer. We compile OOProgramer and recompile JavaProgrammer. The vtables are shown in Figure 4. Clearly, the vtable layout of JavaProgrammer has changed. The line for Jerry.study in Manager is going to call method drink which happens to reside in the entry 2 of Jerry's vtable after the change.

Figure 4: Scenario C: changing class hierarchy.

The lesson is, binary changes may occur after some classes are loaded. Static dependency analysis and recompilation are sometimes not only undesirable, but unaffordable. Reflection is an additional complication.