Negligent Class Loaders for Software Evolution.
Yoshiki Sato, Shigeru Chiba · 2004
Modern software should be dynamically evolvable. The onward sweep of technology, introducing new features, and fixing immortal security holes, drive this evolution. Moreover, practical demands of on-the-fly changes of running applications eagerly encourage the evolution since the downtime of commercial software directly causes big losses. Enabling the evolution of software components is a major focus of efforts of the designers of imperative, static typing, and high-performance languages, such as C++ and Java. Recently, the ability of Java’s class loaders, which play a central role in runtime flexibility of Java, has been considered to be insufficient for software evolution. Java class loaders do not allow reloading classes that have been loaded since to allow reloading a class tends to make several crucial runtime optimizations difficult [6]. Instead, Java class loaders provide a mechanism for using different versions of a class at the same time although the use of this mechanism is restricted. This restriction is called the version barrier. This paper presents a negligent class loader, which can relax the version barrier between class loaders for software evolution. The version barrier is a mechanism that prevents an object of a version of a class from being assigned to a variable of another version of that class. In Java, if a class definition (i.e. class file) is loaded by different class loaders, different versions of the class are created and regarded as distinct types. If two class definitions with the same class name are loaded by different loaders, two versions of the class are created and they can coexist while they are regarded as distinct types. The version barrier is a mechanism for guaranteeing that different versions of a class are different types. Regarding two versions as distinct types is significant for performance reasons. If not, advantages of being a statically typed language would be lost.