Recommendations for compatibility between OSGi platform releases

Question

Assuming that it's even possible, what would be your recomendations to make a bundle compatible between different platform releases? Specially between R3 and R4.

Update about my requirements:

The idea was to develop a web interface for a embedded device that currently runs an OSGi R3 container but that it could be upgraded soon to R4 (we don't have much control over this). The web interface will be deployed using a OSGi HTTP service. I see three options:

• Do the application with R4 as I've seen that some web toolkits doesn't work with older releases. I suppose that the providers of the device could deploy the current R3 bundles on R4 without much effort (but not sure).
• Implement the web interface with R3 and without the benefits of modern web toolkits (or recommend me one).
• Do it with some R4 bundles but some-way release-independent so we can finally deploy it on R3 or R4.

Answer 1

In general, R4 mostly introduced new headers for the bundle manifest, which R3 implementations ignore. There are a few semantic differences in import/export behavior but depending on what kind of bundle you're making, those might not matter. One strategy you could use is to simply create an R3 bundle, which should still work fine on an R4 framework. You'd miss out on some new R4 features in that case, of course.

Follow up:

From the point of view of the HttpService, there are no big changes going from R3 to R4.2. The former uses the 1.1 specification of HttpService, the latter 1.2. The differences are minor (the spec uses the @since tags in the API documentation to explain what methods were introduced when).

It is completely true that R3 bundles work as is on R4. Keep in mind though that in practice you could discover bugs when running R3 bundles in R4. When R4 was just released, I moved a big project from R3 to R4 and we encountered lots of small issues, all our own fault, which caused bundles to fail on R4 while they were happily running on R3. These were mostly related to R4 implementations in general being more strict when it comes to delegating to their parent classloader. Make sure you test your bundles on the frameworks you want to deploy them on.

I am wondering, in what way do the web toolkits you looked at not work on R3? Do they depend on HttpService 1.2? I guess it would not be hard to run 1.2 on R3 yourself, or bridge it to an 1.1 implementation.

Answer 2

I've developed bundles since R1 and they still run on R4 frameworks. Backward compatibility is an essential point for the specification work. But as Marcel points out, some more details on your requirements would be helpful.

Update Is there a business or technical requirement that you cannot use R4? Well, If you just implement a servlet-based service using the standard HttpService you should not expect any problems when moving the bundle to an R4 framework. However you can and should start using the R4 manifest properties. They are ignored in R3 but are very helpful in resolving dependcies in R4 and later.

If you are limited to an R3 framework I would always do a test run on an R4 framework in parallel on a regular basis to ensure that everything is still ok. Not much effort at all.