alek blogs

Java Package Versioning is not easy...

As I have discovered after few hours of frustration support for versioning in Java is awkward and is based on Package Versioning spec that has only HTML description but does not have a working example (article in JavaWorld and working example provided were very helpful to figure out what was going on ...)

This is one of those rare moments that i wish i used other programming language than Java where they better solved this issue. for example it turned out that it does not work until at least one class from package is loaded into application and instead of trying to load package classes the API simply returns null exactly the same value if package is not available at all in current classloader - so the developer needs to guess why null was returned ...

My main problems are that it is only package based (i can always just version one package for library for simplicity) and it not possible to use API if code is not in JAR file and that is big problem. in such case Package.getPackage("package") returns not null but all calls to get getSpecificationVersion() etc. will always return null as implementation completely ignores my MANIFEST.MF even though it is on CLASSPATH but it is not in JAR file (one more reason to have real class metadata support in Java ...)

one nice thing i found is good and useful schema for assigning version numbers with MAJOR[.MINOR][.MICRO][_PATCH_NUMBER|-MILESTONE_NUMBER],
for example: 1.1, 2.20.1, 3.4.5_03, 4.5-beta1 (more details in notes about Specification-Version and very good rationale on not making implemntation versions comparable as described in Rationale for Limiting Implementation Version Numbers to Identity, excerpt:

A bug first appears in some version of a vendors package and may or may not continue to be a problem in subsequent versions. If the client of the buggy package uses a workaround based on version numbers, it could correctly work around the bug in the specific version. Now, if the buggy package was fixed, how would the client package know whether the bug was fixed or not? If it assumed that higher versions still contained the bug, it would still try to work around the bug. The workaround itself might not work correctly with the non-buggy package. This could cause a cascade of bugs caused by fixing a bug. Only the developer, through testing with a new version, can determine whether or not the workaround for a bug is still necessary or whether it will cause problems with the correctly behaving package. The developer only knows that the bug exists in a particular individual versions.

current solution: define package.Version.check(String version) (example in XSOAP) and not waste more time on it ...

created sat feb 20 2003 8:20pm est [2003/2/20 20:20 EST] permalink

This blog is about:
XML, Java, and everything else (or nothing ..)

Find more about
blog author

Blogroll:
Sam Ruby
Russell Beattie
Diego Doval
Joel on Software
and some (almost) harmless entertainment: The BileBlog

Projects::
MicroLogger
Xydra
WSIF
XmlPull API
XPP3/MXP1
XSOAP
XMessages

RSS
0.92 [validate]
2.0 [validate]

Filter Entries:
Life
Java
XML
Computing
Web Services