JSR 277 – Mostly Harmless or a Good Thing For OSGi?

newClash-730586.jpgBryan Atsatt, who is House Harkonnen’s representative on the JSR 277 expert group, has been doing a lot of work trying to bring the two warring parties together and not simply salvage the relationship but to turn the momentum around and spark a new found friendship between the two.
His first post on his new blog is dedicated to this premise, JSR 277 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.
The emPHAsis is on the wrong syLLAble.
The api/framework layer must be the primary focus of the JSR 277 specification, providing a coherent compile/runtime model that enables multiple implementations. Specific implementations, while required to surface framework/api issues, should be documented in appendices or even separate specs.
If the EDR spec had been written from this perspective, we probably would have avoided most of the current animosity. We can and should fix this in the next draft release. Implementations can then be seen on equal footing. More importantly, they can be left to compete on their own merits.
Not everyone wants or needs OSGi, and the new .jam implementation may be right for them.
But we know that there will be LOTS of bundles around when SE 7 ships, vastly outnumbering .jam files, so we need an OSGi implementation. ASAP. Built by OSGi insiders. Without it, we cannot have confidence that the api/framework abstractions are right or complete. With it, we not only gain spec validation but have a ready-made solution for using bundles on SE 7.

Give it a read.

Leave a Reply