The Artima Developer Community
Sponsored Link

Java Buzz Forum
Java Package Versioning is not easy...

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Aleksander Slominski

Posts: 51
Nickname: aslom
Registered: May, 2003

Aleksander Slominski is a Ph.D. student at Indiana University working on components, XML, and grids.
Java Package Versioning is not easy... Posted: Jul 17, 2003 6:11 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Aleksander Slominski.
Original Post: Java Package Versioning is not easy...
Feed Title: alek blogs java
Feed URL: http://www.extreme.indiana.edu/~aslom/blog/java/index.xml
Feed Description: discovering limits of programming
Latest Java Buzz Posts
Latest Java Buzz Posts by Aleksander Slominski
Latest Posts From alek blogs java

Advertisement

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][_PATCH_NUMBER|-MILESTONE_NUMBER], exmaple: 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 ...

Read: Java Package Versioning is not easy...

Topic: JVMs on PDAs Confusion Previous Topic   Next Topic Topic: Meta Tags Revisited

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use