Are JSR277 and OSGi coming together?

Posted by Alex Blewitt on May 19, 2008

Community

Java

Topics

Technology ,

Language

Tags

JSR 291 ,

OSGi ,

JSR 294 ,

JSR 277

Last month's piece on the status of the JSR277 and OSGi (aka JSR291), sparked a fresh debate on the JSR277 expert group mailing list, clocking up its biggest monthly total so far this year. One of the main drivers behind this has been Bryan Atsatt, a member of both the JSR277 (modules) and JSR294 (superpackages) expert groups. He argues that JSR277 could be great for OSGi:

The initial spec actually has two separate parts: an api/framework, and an implementation with a new distribution format. Unfortunately, these are presented in a way that seriously blurs the distinction. Worse, the new distribution format (".jam" files) often takes center stage.

So how could JSR 277 be great for OSGi? By providing tight integration of bundles into SE environments. The benefits would surface in four main ways:

• Canonical storage model
• Compile time dependency resolution
• Class/resource sharing across module implementations
• Command-line execution

And this could all work for existing OSGi bundles. Could be nice, huh? Maybe there's hope yet.

In fact, Bryan has been the driver for a number of the recent posts on the JSR277 expert group; he raised the point that the specification should be separate from the implementation, as these are mixed in the presentation of the expert draft review; and that Peter Kriens should be brought on board:

This EG has stagnated and needs to be brought back to life. I'd like to propose these concrete steps:

1. Add Peter Kriens to the EG. Peter has clearly demonstrated great expertise in this area, and I believe he would quickly become a valued, active contributor.
2. Bring the interop design/discussion/investigation process out of Sun offices and into the EG.
3. Give the EG read access to the tip of the source tree (or at least very current snapshots).

Indeed, it seems that most of the discussions and implementation decisions are being done behind closed doors at Sun, and treat the expert group as proof readers after the decisions have been made. In fact, both of these points were highlighted by Peter Kriens not wanting to be involved in the current state:

However, JSR 277 now consists of two good (Repository and Language modules) and one bad part (JAM). Just before JavaOne 2008 Stanley had published a brief OSGi interoperability document. This document was not only very thin on details, it also referred in many places to an invisible Early Draft #2 (EDR2). I asked the EG members BJ Hargrave [Equinox - ed] and Richard Hall [Felix - ed] if they had seen this EDR2, but it was unknown to them as well. I had recently complained about the lack of discussions on the JSR 277 mailing list, so it seems that work had been going on stealthily.

During the JSR 277 presentations Alex and Stanley it became clear to me that a lot of work had happened behind the scenes; Without any communications on the mailing lists. For somebody in the audience it was absolutely not clear that almost everything that was said was never discussed in the EG. How could I participate in an EG if the only option would be to approve work done at Sun behind the curtains? How much change can there be if the unpublished EDR2 is presented at JavaOne as the stable result for JSR 277? Should I join an EG where most of the work was already done? How many fundamental changes can you achieve in this situation?

We are now at a crucial point in time. Though I'd love to participate in the discussions about modules in the Java language and the repositories, I cannot become responsible for a module system in Java that is creating this complexity for no rational reason. I do hope Sun will take this last step as well, and drop JAM in favor of the much simpler approach of using the OSGi metadata throughout the system. In the last months we have gotten so far! Please?

Meanwhile, fresh involvement at Sun means that the OSGi interoperation is looking up. Alex Buckley has joined the 277 expert group (and was responsible for the aforementioned simplification of JSR294, which was met with great acclaim); and Mandy Chung has been tasked with working on OSGi interoperability.

It seems that Sun have been listening, and not before time. At JavaOne this year, we reported on the OSGi-based Spring Source Application Platform and Glassfish running on OSGi. The OSGi best practices presentation (PDF) sparked a fresh interest and since JavaOne there has been a increased number of discussions on forums and blogs about bundles. We can hope that the JSR277 EDR 2 will have taken all of these points to heart and will bring OSGi and JSR 277 closer together.

• Older >