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 ...)
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 ...