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.
2 comments:
In my opinion, there is good reason for the JSR 277 group to take a fresh holistic perspective on module management and come up with something new. OSGI is many years old and is based on limitations and technologies that were a part of the old JVM 1.2 specification.OSGI was just a band aid to address legitimate limitations of the Java platform.
If Sun and others want to take a fresh approach and address the concept of modules from the top down I don't see why they shouldn't do so.
@nickmalthus
That's fine in theory, so long as the result of such an effort was actually an advance on OSGi and also provided a clean migration path for the very large number of existing OSGi bundles.
What we got in the EDR in late 2006 was neither of the above. JSR 277 as currently defined is far less powerful and useful than OSGi, and nowhere near as ambitious in its scope. This is despite OSGi being, as you put it, "just a band aid" which works on all versions of Java from 1.1 upwards. Remember, those ancient Java limitations still exist today in Java 6, which is why so many people are adopting OSGi, including Sun themselves who just announced that GlassFish V3 would use it.
If the JSR 277 expert group were to define a new module system that was more powerful than OSGi and included compatibility for "legacy" OSGi bundles then I think the majority of the OSGi community would be very pleased. That's exactly what Bryan (the author of this blog and a member of the JSR 277 expert group) has been trying for 2+ years to push Sun towards. And it seems like they might have actually started listening at last.
Keep up the good work, Bryan!
Post a Comment