Versioning for JOS

<B>Prepared by Chris Bergstresser ( <external mailto:chris@subtlety.com>mailto:chris@subtlety.com</external> )
Version 0.1
28 Oct 1997

In the design and deployment of object-oriented systems, versioning is a critical requirement. This document attempts to briefly describe the problems associated with versioning for Java, explain what API's Sun is creating to help solve the problem, and propose a workable system for JOS.

The Problem

There are a number of problems associated with deploying programs which rely on a set of heterogeneous components external to the program. These include:

Distribution of incompatible versions

A new version of a class may be Incompatible with previous versions. Software designed to run with one class may behave erratically when used with a later version.

Update of old versions

Newer systems may rely on a set of classes which are outdated on the target system. Thus, the installation of a single component may require the updating of any number of other components.

Synchronizing of existing distributions

In a distributed environment, it is possible that some systems may be using old versions of a class, and may continue to use the old version while interacting with newer versions on other computers. Indeed, it is possible (in fact, likely) that within the same system a given program may have some classes loaded in a classloader or serialized to disk while the source for the class is changed.

A more detailed examination of the problem, as well as Sun's pre-release specification, can be found at http://java.sun.com/products/jdk/1.2/docs/guide/versioning/spec/VersioningTOC.doc.html

Upcoming APIs

Sun has recognized the problems with distributed systems, and is publishing a versioning specification for inclusion with a later version of Java.

Package-level distribution

The basic unit of distribution for Sun is the package. All the classes in a given package are distributed in bulk. There is no provision made for updating individual classes within a package.

Archive support for versioning

Packages distributed in an archive must report their versioning information through the manifest file. This file contains information about the Title, Version Number, and Vendor for both the implementation which is being distributed as well as the specification which the implementation adheres to.

Classloader changes

The classloader is responsible for tracking the versions of packages currently loaded, for use in debugging.

Compatibility issues

Sun's versioning API makes the assumption that all changes to a specification are backwardly compatible. All serializable classes must insure they can deserialize and be deserialized by older versions. Interfaces are not permitted to add, change, or remove methods. Classes are not permitted to remove or alter existing methods. Sun's versioning specification provides no way to indicate that a given package is incompatible with a previous one.

Implications for JOS

Package-level upgrading

JOS should use Sun's definition of a package as the minimal unit of distribution. Exceptions will be made for "packageless" classes -- factory objects, small utility classes, and drivers which do not make sense as a part of a larger distribution. The classloader should track these pieces individually.

Dynamic upgrading of a package

When a set of classes is upgraded, the new classes will be copied to the local system. The old classes, which are to be replaced, are not removed. Instead, packages already loaded in classloaders will still exist, and will continue to do so for as long as a class remains loaded in memory. Once all of the classes in an upgraded package has been unloaded, the next loading of a class from the package will use the new version. The system is free to erase the previous package. If the package in question is a system-wide package, replacement will require a reboot. For packages loaded locally to a process, this can be an incremental process; new processes can use the new classes, while old processes can continue using the old. As long as Sun's compatibility rules are followed, there should be no problems with this model.

Incompatible versions

It may be desirible to install two different versions of the same package on the system. This can be accomplished by having the classloaders for different processes refer to the different versions, thus preventing them from being loaded into the same space. This causes a problem from two points-of-view. First, it requires a knowledgeable administrator to actively track down the incompatibilities and specify which processes should use which versions. Second, this will not work for system-level packages, since they must be shared among all processes (and as such, cannot use different versions).

Open questions

Recovery of previous versions

There should probably be a mechanism in place where, once a given package is upgraded, the previous version can be recovered and reinstalled if the new one turns out to be unworkable. Suggestions?

Definition of system packages

System packages are defined as those packages which are shared among all classloaders. Obviously (or not?), the jos.* packages would fit into this catagory. Individual user's classes would not (or would they?). The question is mostly whether the java.* packages should be, or should not be, or whether this should be user-configurable or not. This has an effect on other portions of JOS -- for every package that is not shared, a separate copy must be kept in memory for each classloader that references it.

It might be possible to define an intermediate level of sharing -- a class is shared among all the user's processes, but not system wide. This would cut down on memory use, but greatly increases the difficulty managing upgrades.

Discussion of incompatible versions

How much faith do we give Sun's versioning spec? How likely is it that incompatible versions will surface, and (more to-the-point) that we will need to run incompatible versions of packages side-by-side in the same system? The answer to this question determines how much effort we need to put into the above. Obviously, if there is no need to run incompatible versions in JOS, things become much easier.

If I may say so, Sun's versioning spec doesn't solve Sun's own problems with three versions of Java (1.0.2, 1.1 and 2.0). It is woefully inadequate and, as history may show, could be Sun's fatal flaw. Sun may lose control of Java because they failed to keep their promise of Write Once. From our 10+ years experience with extreme distributed computing, Sun's whole versioning premise is misguided. Such a shame, too. With three versions of Java and all of the trouble they have caused their customers, Sun wonders if they are in trouble; but, their versioning solution is a dead end. The correct answer is so simple it is often overlooked and it is namespace.
1. Sun named Java 1.0.2 as java.*;
2. Sun mistakenly named Java 1.1 java., too; and should have named it java.11..
3. Sun mistakenly named Java 1.2 java., too; and should have named it java.12.;
Architecture is supposed to solve entire worlds of problems. If Sun would have named new and incompatible packages thus, versioning would have been a non-issue. Looking ahead, JOS should be expected to have different versions, too.
1. JOS 1.0.x could be named jos.10.*
2. JOS 2.0.x could be named jos.20.*
3. JOS 5.3.x could be named jos.53.*
The trouble with versioning doesn't immerge until you start the second version. Look to Sun for advice on versioning if you think they have a perfect track record on it. - GilbertHerschberger
Finding the simplest versioning approach is the goal. After working with versions in Java for a while, the simplest approach seems to be the following:
- Everything related to JOS could be named org.jos.
- Releases of the JOS core could be named org.jos.core1a, org.jos.core1b, and org.jos.core1c;
- Releases of the JOS I/O subsystem could be named org.jos.io1a, org.jos.io1b, and org.jos.io1c;
- Releases of the JOS application framework could be named org.jos.app1a, org.jos.app1b, and org.jos.app1c; and
- Releases of the JOS Abstract Windowing Toolkit could be named org.jos.awt1a, org.jos.awt1b, and org.jos.awt1c.
In practice, every package should be independently released. There is no version 2 of JOS as a whole. There are only second and third releases of some packages within JOS. - GilbertHerschberger

Content of these pages are owned and copyrighted by the poster.
Hosted by: