Is platform enforced versioning mechanism most sorely needed feature of java?

Question

As developer, I am often interested in new language feature that can make your life easier. For example, java 5 brought generics and annotations to the language, features that can definitely boost your productivity.

However, when I look back at close to a decade working on java platform, I find that the versioning related problems are the biggest culprit of unproductive and needlessly spent effort. Hours and hours of looking for the correct version of the jar, trying to reconcile some versioning conflict, upgrading dependent libraries etc. When I started working in java, things were not that difficult, you’d have a few 3rd party libraries and that’s it. Today, your typical web app might easily use: Spring Framework, Hibernate, Struts, you name it. All of these carry a number of dependant 3rd party libraries. Today, my ear archives will typically include some 40 or more 3rd party libraries. A real jar hell!

With annotations, I don’t have to manage config files for Hibernate for example. A nice feature, but I haven’t seen that many problems arising from the fact I keep my descriptors in separate file. With generics, I am spared from writing cast statements, but in my whole programming carrier I can’t remember a single bug that could have been prevented by using type-safe container. Wouldn’t solution to versioning problems have been much more valuable?

All these problems have resulted in number of tools like Maven, ivy, One Jar, Jar Jar Links (not kidding!), even appropriately named Jar Hell etc. Even if you use some of these tools, you are far from being immune to the problem. I use Maven 2 and it has been a great help. Still, it is a world to itself. Novice programmer can take a while to learn it. Moving your legacy projects to Maven structure is also a pain.

It seems that in .Net they have learned the lesson with dll hell and management of .Net assemblies is much simpler.

There seems to be plans to solve this problem for java platform and alternatives like OSGI. I think that some basic and platform enforced versioning mechanism is badly needed

Answer 1

I've also been using Java for over a decade but I have to say I haven't found many JAR hell issues at all (even using all the 3rd-party tools you mention)! I found Maven to be a horrible tool, so build everything with ant.

At our company we have a bespoke dependency-resolution ant task based on a simple (small) dependency file for each project, together with defining each project as either an app or a lib (you should only ever depend on a lib; never an app). It works just fine.

We also have ant tasks to modify our eclipse .classpath and IDEA .iml files to generate dependency graphs for our IDEs.

Answer 2

Take a peek at OSGi - it deals with versioning and management of bundles (jars) very nicely.

ALSO: Eclipse (which is built on top of OSGi) has some relatively new API Tools that can help you compare your API against a previous baseline and determine how to appropriately express the next version number of your bundles.

The general eclipse versioning scheme:

v.m.n.q

where

v: high-level version - changes here represent generally breaking changes in the API

m: major changes - new functionality, new API

n: minor changes - same API, behind-the-scenes changes

q: qualifier - useful to mark builds, alpha/beta, etc

OSGi specifies version dependencies using ranges. For example

Require-Bundle: com.javadude.foo;bundle-version="[1.2.0,2.0.0)"

in your MANIFEST.MF specifies that the bundle requires version 1.2.0 or later of bundle com.javadude.foo, up through (but not including) version 2.0.0.

You can also specify dependencies at the package level instead.