|
|
[ Index ] [ Individual Project ] [ Placement Presentation ] [ Timetable ]
[ Index ] [ Research ] [ Schedule ]
This chapter describes what properties the class file (compiled binary) must have to preserve binary compatibility. The rest of the chapter describes the various evolutions that a class can take to ensure binary compatibility. Listing them here would merely be copying out the entire chapter and putting it on the web.
The chapter does begin with a nice quotation:
Despite all of its promise, software reuse in object-oriented programming has yet to reach its full potential. A major impediment to reuse is the inability to evolve a compiled class library without abandoning the support for already compiled applications....[A]n object-oriented model must be carefully designed so that class-library transformations that should not break already compiled applications, indeed, do not break such applications.
Source: Ira Forman, Michael Conner, Scott Danforth, and Larry Raper, Release-to-Release Binary Compatibility in SOM (1995)
13.4.7 Field Declarations - When a subclass is altered so it shadows a field of its superclass and changes the type of the class the JLS states that any classes that refer to field in the superclass with still use that field to ensure compatibility. Future recompilations will break this. A result of this is the subtle error that when the subclass changes to shadow a superclass field, but keeps the same type the value from the superclass is used and only a recompilation will allow the new value to be seen. Apparently this particularly issue has been resolved in Java 1.4, but not explicitly. This would in fact violate part 13.4.7 of the spec, but since it is correcting undesired behaviour without breaking existing applications, it should not matter, but warrants further investigation.