Many OSGi advocates have said they wish JSR 277 would "just die". Why? Because 277, as currently defined, seems to thumb its nose at this mature, widely adopted and rapidly growing modularity solution.
OSGi is the de facto standard in this space, yet in JSR 277 Sun has defined an entirely different, apparently competing solution. Targeted at a future SE release, 277 appears to undermine OSGi by casting doubt about its future role in the Java universe.
So yeah, OSGi adopters are pissed. Understandably so.
But there is a another way to look at it. Really. If you squint your eyes a bit at the early draft spec, you can see it.
Big, deep breath... exhale slowly... Good. Ready?
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.
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. The Repository abstraction provides extensible installation and search mechanisms for any module system. The Query abstraction enables flexible, extensible, indexable searches, over both local and remote repositories.
Compile time dependency resolution. The ModuleDefinition and ModuleContent abstractions, coupled with Repository, enable the compiler to actually use the runtime machinery to perform dependency resolution, ensuring high fidelity with runtime environments. (These same abstractions enable interesting tools other than compilers, as well.)
Class/resource sharing across module implementations. The Module and ModuleSystem abstractions work together to enable sharing at the ClassLoader level, across different module systems. (And yes, the exact mechanics of this are still TBD; again, we need an OSGi implementation to help flesh this out.)
Command-line execution. Like the -jar option, a -module option will enable convenient execution of a main class from any module, backed by full version/constraint based dependency resolution. A -repository option provides flexibility in directing the search for the specified module.
And this could all work for existing OSGi bundles. Could be nice, huh?
Maybe there's hope yet.
OSGi is the de facto standard in this space, yet in JSR 277 Sun has defined an entirely different, apparently competing solution. Targeted at a future SE release, 277 appears to undermine OSGi by casting doubt about its future role in the Java universe.
So yeah, OSGi adopters are pissed. Understandably so.
But there is a another way to look at it. Really. If you squint your eyes a bit at the early draft spec, you can see it.
Big, deep breath... exhale slowly... Good. Ready?
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.
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. The Repository abstraction provides extensible installation and search mechanisms for any module system. The Query abstraction enables flexible, extensible, indexable searches, over both local and remote repositories.
Compile time dependency resolution. The ModuleDefinition and ModuleContent abstractions, coupled with Repository, enable the compiler to actually use the runtime machinery to perform dependency resolution, ensuring high fidelity with runtime environments. (These same abstractions enable interesting tools other than compilers, as well.)
Class/resource sharing across module implementations. The Module and ModuleSystem abstractions work together to enable sharing at the ClassLoader level, across different module systems. (And yes, the exact mechanics of this are still TBD; again, we need an OSGi implementation to help flesh this out.)
Command-line execution. Like the -jar option, a -module option will enable convenient execution of a main class from any module, backed by full version/constraint based dependency resolution. A -repository option provides flexibility in directing the search for the specified module.
And this could all work for existing OSGi bundles. Could be nice, huh?
Maybe there's hope yet.
