Arieh's Weblog

A technical discussion in an internal forum here at Sun and a subsequent conversation with a colleague are the motivation for this post.

The issue in question relates to the determination of versions (at run-time) for Java code. The initial point of discussion was the seeming lack of established convention for the versioned names of jar files. The analogy brought up at the time related to the conventions that exist for naming of .so shared objects in Solaris and Linux (which btw, are different).

Personally, my perspective gravitated more towards the ability to determine versions, but not of the 'jar' file, as much as to determine the version of a specific Java class at run-time, for the purpose of compatibility check, and perhaps even conditional execution.

Work I did back in 1998/1999 within the StorEdge Component Manager project addressed that issue.

The idea is based on the Jar Manifest section in the Java tutorial.
The Java Versioning Specification is available here.

The solution is based on the existence of a Manifest File that is included in the jar file. One thing worthwhile noting is that there may be more than one manifest entry

    Name: com/mycompany/mypackage/
    Specification-Title: My Package Specification 
    Specification-Version: 1.3.0.0
    Specification-Vendor: My Own Company, Inc. 
    Implementation-Title: com.mycompany.mypackage
    Implementation-Version: 1.1.0.1 
    Implementation-Vendor: My Own Company. Inc.

in the jar, thus allowing to specifically version every separate package.

Taking this a bit further, we proceeded to include on every package a Version class that extends from a super-class that defines methods allowing to perform comparisons between versions, to determine equality, earlier-than, later-than, parsing version to extract major/minor revision information, etc.

The common-build-enviroment used provided for automation of the creation of the Version classes, driven off external files where the versioning information appeared as metadata. Further utilities to generate the MANIFEST.MF file and its incorporation into the jar-file were developed.

The solution presented provided a reasonable implementation of what the specification stated. Establishment of the infrastructure and methodology of application was key in effectively using it.

It will be interesting to hear from those of you who may have run into similar issues and to share your own experiences and solutions.