Negative Qualifiers

Some face time with your colleagues can sometimes be really productive. Last week we had an EG meeting at IBM in my home town Montpellier. As I've known BJ Hargrave (IBM) and Richard Hall (Oracle/Apache Felix) for so many years I'd invited them to stay in our guest house. After arriving around noon we took the afternoon off to solve world hunger and climate change over a glass of rosé. As too often happens in these important discussions, we were seriously distracted with versioning strategies.

The OSGi version is defined as linearly increasing where the floor is the shortest form of the version. That is, 1.2.3 is less than any other version that starts with 1.2.3. A side effect of this model is that it is hard to model pre-release versions. A common approach is to use a snapshot version for artifacts that are on their way to becoming a release version. For example, 1.2.3-SNAPSHOT indicates that this artifact is becoming version 1.2.3 but is not there yet.

You can do this in OSGi with the qualifier but it is awkward because you want the final release version to be sort highest. Like 1.2.3.A1, 1.2.3.A2, 1.2.3.FINAL. The fact that you cannot just release 1.2.3 but have to use 1.2.3.FINAL generally offends our highly developed aesthetic sense.

The maven solution is to use a magic keyword: -SNAPSHOT. However, we felt a bit uncomfortable with a magic keyword. The qualifier in OSGi is left open for enterprises to implement a release strategy and it would be nice if they could do the same with a qualifier that came before the actual release. So why not have negative qualifiers?

The syntax for the OSGi qualifiers specifies a period as separate between the version and the qualifier, for example 1.2.3.qualifier.  If we allow a minus sign instead of the period we can interpret the qualifier as coming before the version instead of after. That is, 1.2.3-qualifier is actually less than 1.2.3. This contains the special case of -SNAPSHOT but enables the use of qualifiers to track build, patch, or other variations.

So what about ranges? Bundles that depend on artifacts normally specify a range like [1.2.3,1.2.4). I think this should include a version like 1.2.3-SNAPSHOT but there was some discussion about this, some wanted snapshot only when the range indicated snapshots, e.g.[1.2.3-,1.2.4-). For me this is awful because it requires rebuilding and retesting after you released. In think [1.2.3,1.2.4) must accept any negative qualifiers on 1.2.3. The discussion is ongoing.

Negative qualifiers would really help bndtools. We could always build with a 1.2.3-${tstamp} to capture the build time. If one day the artifact is released, we take the JAR and convert the minus in the version to a period. For example, the artifact has version 1.2.3-201106261020 if it comes from the development tree/repository. Once it is released, we change the manifest to version 1.2.3.201106261020 inside the release repository. No need to recompile or retest.

There are some loose ends with version ranges but I am sure we can work this out. However, the fact that got excited about this idea (world hunger has to wait another meeting) does of course not mean that the OSGi will start using this model tomorrow. BJ is working on an RFP to there is hope for the future. If you have any ideas, let us know.

Peter Kriens

Ease of Use and Spring

Things should be as simple as possible, but not simpler.

As true as this is, the boundary between simple and simplistic is unfortunately highly subjective. If something works for you, don't change it. Unfortunately, many developers are in a situation where the environment and problems are highly complex and OSGi can simplify such situations.

The primary value that OSGi brings to the table is when you have to maintain a large code base over long periods of time, you have many external dependencies, you need to provide middleware, if you work with multiple developers, or if your development is spread over multiple locations. For those situations OSGi provides a type safe module extension to Java that can significantly reduce your development complexity.

So what is the usability issue? Unfortunately, both the modularity and type safety are at odds with prevailing class loading patterns in Java. OSGi is often the messenger telling you that your baby is neither modular nor really type safe. For example, Dependency Injection in Spring requires access to implementation classes from the configuration, exactly the classes you should really keep private. Worse, dynamic loading is only type safe if there is a single namespace in the universe. A single namespace causes DLL hell aka JAR hell that OSGi prevents by managing multiple class name spaces in a type safe way.

These are not OSGi problems, if Jigsaw one day will be modular and type safe it will have exactly the same issues!

To get the many benefits of modularity and type safety you must therefore change the way you think about Java ... If something is inside your module everything works as before but if you want to work with other modules you need to consider type safety and module boundaries. Object Oriented Design forced you to consider inheritance, encapsulation, and object identity, things that did not exist in Structured Design. Java modularity requires just such a paradigm shift. What we need is an inter module communication mechanism that truly hides implementation classes and enforces the type safety across modules. OSGi services are such a mechanism.

As Spring heavily relies on dynamic class loading it ran head on into the module boundaries and multiple name spaces. The resulting mess is what causes the negativity. Though Spring DM included OSGi services the problem was that they were more supported than embraced, resulting in many Spring DM/Blueprint modules to use the existing dynamic class loading model. However, this results in the import/export of large numbers of implementation classes. Exporting/Importing implementation classes increases the public space, the opposite of modularity. The history would be very different if the Spring libraries had embraced services, setting an example for true modularity.

There are only two solutions to this problem: Change OSGi or change the world. As I do believe there is no value in a little bit of modularity I can only see false advertising value in punching convenient holes in the modularity story of OSGi.  I do believe it is worth keep strong modularity and its enforcement. Very large applications like Eclipse, Websphere, JDeveloper, and others demonstrate that at certain scales OSGi becomes a necessity. And as more and more open source projects start to embrace OSGi it will become easier and easier to build OSGi based systems.

That said, as Rod justly points out, there are lots of people that are happy with Tomcat and depend on hard core dynamic class loaders. The OSGi service based programming model could provide benefits to these applications even if it did not enforce the boundaries. We're therefore thinking about a version of OSGi that inherits the class loading architecture of whatever environment it runs in; a JAR on the class path is then treated as a bundle. For example, in a WAR all entries in the WEB-INF/lib directory would be available as bundles. Karl Pauls tested this and it is a testament to modularity that many existing bundles actually worked out of the box. Though this solution obviously does not help when you are in JAR hell, it does provide many of the benefits of OSGi in your own familiar environment. And one day, when JAR hell finally arrives, the OSGi Service Platform is there to serve you.

Peter Kriens

Masterclass on OSGi

Neil Bartlett and I are organizing a Masterclass on OSGi in the Stockholm archipelago from August 30 to September 2. In this masterclass we provide a thorough schooling in OSGi (using bndtools) but we also have a chance to explore the areas the attendees are interested in. The last Masterclass was a great success and we intend to repeat this success in Stockholm. One interesting aspect was that experienced people that had been using OSGi for several years were surprised how much easier OSGi had become.

Though we've a places left there is a bit of urgency because the hotel indicated that the rooms are becoming scarce. As the masterclass usually runs into the wee hours of the night it would be a pity if you had to stay in another hotel.

You can find all the details here: Masterclass on OSGi.

Peter Kriens