A Puzzle for the Community Event

Next month we're having the community event in Darmstadt, Germany, Sept. 20 and 21 (with Alex Blewitt as keynote btw). Now before you click away because you were just hoping for some juicy Jigsaw information, I'd like to challenge you! I was inspired by Masquerade, an amazing puzzle book, after seeing a documentary about it on BBC 4. I therefore decided to create my own puzzle. Not in the league of Masquerade but I think it is sufficient complex to keep some geeks like us busy. The first prize is a free registration for the Community Event. It also happens to be the only prize (and I'll buy you a drink at the Community Event if you found all the answers).

If you're really clever enough to solve it but just too slow to win then do not hesitate to send me a mail because I am interested in anybody that is clever enough to solve this puzzle.

Kit Williams, the author of Masquerade went into recluse after his puzzle went viral in the late seventies. He is living in a hideaway in Gloucestershire in England still making amazing art but in general shying away from public. I am pretty sure this puzzle is too geeky to get that kind of following.

Anyway, go solve the puzzle if you can!

Peter Kriens

Join us for the Community Event, 20&21 September 2011

It is time to register for the OSGi Community Event in Darmstadt September 20 & 21! We have a really good agenda this year and lots of OSGi people will be present. Looking at the lunches map, we should have quite a lot of attendants as we're in the heart of the OSGi Continent.

I'll be chairing a panel on "What Are the Major Tasks to Tackle Within the Next Two Years?" and I will be looking forward to your input.

If you register in the next two days you will get a substantial early bird discount.

I hope I will see you in Darmstadt next month!

  Peter Kriens

The Package as Contract

Contract based design is, from my perspective, one of the best insights our industry had for the past 50 years. With contract based design you separate the providers of the contract and the consumers of the contract. In Java, there is a sometimes tendency to see these contracts as just an interface. The provider is the implementer and the consumer is the client of the interface. I think this is misguided because an interface is way too limited for real life software contracts.

A software contract is a collaboration scenario; the contract designer is the choreographer allowing the provider and consumer safely do their dance. In this choreography, you sometimes need an interface to describe the role of the consumer of the contract; we often call those interfaces listeners. Other times, the onus is on the provider and then we frequently revert to names like managers or servers. Sometimes we need real classes to provide event objects, exceptions, permissions, or small helper classes to make the overall contract easier to use. Sometimes, though rarely, there is even a need for private classes to implement parts of the contract in the contract. It should be clear that a contract is much more than just an interface.

Contracts change over time and this raises the issue of versioning. Most of the time when we talk about versioning we only talk about the provider and the consumer versions. However, the whole idea of contract based the design is that the consumer does not depend on the provider, it only depends on the contract. So in reality, the most important version is not the provider's version, it is the contract version! In most build systems this is very awkward as it forces a contract to be specified by an artifact, the only thing that is versioned. Since the best contracts are well defined, highly cohesive contracts this creates a proliferation of artifacts, containing only a few packages. This is cumbersome so people tend to aggregate them and version them together. Often even bunching them up with a provider! However, a side effect of aggregating contracts is that every contract evolves at the speed of the fastest changing contract, causing many unnecessary version update ripples through your system. If you include a provider, the speed even increases more.

By far the best solution I know how to handle contracts is to take the package in Java very serious. A package is really a module, it has encapsulation (classes, interfaces, and resources)  and it can control accessibility. It provides all we need to define a contract. The only missing thing in plain Java is that packages are unfortunately not versioned.

OSGi was made for design by contract from the start and that is why we've taken packages so serious. In OSGi packages are versioned. This is a lot easier that versioning artifacts, although many believe the opposite. The consequences of a change in a contract package is a lot easier to understand than a change in an aggregation of thousands of classes. In the OSGi we have a lot of experience with package versioning and most packages are still at surprisingly low numbers. We actually maintain the version of a package as resource in the package or an annotation on the package.

Designing by contract also explains why OSGi bundles import and export packages and not require aggregations of thousands of classes. The intention is even that shared packages should only be contract packages. In an ideal OSGi system there is no need of sharing implementation classes.

With this experience behind our belts it is therefore hard to see how Jigsaw will provide a model that seem to ignore these lessons of contract based design in a modular world.

Peter Kriens

OSGi and Lunches

About two years ago I found out that a French OSGi expert (Jerome Moliere) actually lived around the corner. It was quite a surprise because I live in the nick of the woods in a small village in the south of France. However, it is a pretty good combination, the south of France and somebody you can discuss OSGi with. There are a large number of pretty good lunch places within 15 km radios and there about 30.000 wineries in a circle of about 100km. So since that day we regularly meet for lunch and enjoy the good life.

So why should you care? Well, I ran into a link to a Google Shared Spaces. Google shared spaces is one of those powerful but simple ideas. A shared space is a link where people can share information that is then visually aggregated. You can share a map, voting, a drawing, text, shopping list, etc. Anybody that has the link can modify the shared space. I had to think of one of those shared spaces when I saw the Map cluster. Would it not be fun to find out who in your neighborhood has some interest in OSGi? Having lunch or a drink in the local bar might be really helpful. Just think of how much more fun it is to complain about class loaders when you're not alone? Or just think how nice it is to show something cool that you've made to someone that actually has a clue?

For this reason I've created a shared map where you can just add your name and location to the map. I know we developers are not known for our outstanding social skills but it is worth a try! So do not be shy or lazy. And if you get a good chapter together you can always invite me for lunch!

You can find the map here: http://goo.gl/61MKk

Peter Kriens

(Follow on Twitter)

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