Java Modularity – Time to Set Sail
Blogger: Kirk Knoernschild
About 18 months ago, I published OSGi in the Enterprise,
with help from my esteemed colleagues, of course. In the time that’s
passed, a lot has changed. Alex Blewitt has already provided an
excellent overview of many of the interesting events that have occurred
over the past several months in his InfoQ articles, Bundle.update, the Current State of OSGi, Bundle.update, OSGi in Java EE, JSR 291 Marked Inactive, and Bundle.update: The Year of Java Modularity.
In
addition to these great overviews explaining where OSGi stands today,
Eclipse has announced two very notable projects worth following: Project Gemini, which aims to provide implementations of the standards developed by the OSGi Enterprise Expert Group, and Project Virgo, which was made possible through the donation of SpringSource dm Server to the Eclipse Foundation. IBM and JBoss are also making great strides in exposing the virtues of OSGi to their enterprise customers, while Paremus continues to innovate with cool products like Nimble. And let’s not forget about Apache Aries and iPojo and Sun’s Glassfish. Of course, the notable list goes on.
The Early Adopters
With all the progress we’ve made over the past 18 months, we’re left with two nagging questions:
- Is OSGi ready for the enterprise?
- Is the enterprise ready for OSGi?
Of course, the answer to each is, “It depends!” Let me elaborate through reference to the technology adoption lifecycle.
When OSGi in the Enterprise was published roughly 18 months ago, I have
no doubt that we were in the Innovators phase. The hype surrounding
OSGi was magnificent and vendors were working feverishly to leverage
OSGi. Yet, without subjecting themselves to a significant burden due to
dearth of tooling, lack of third party modules, and scarcity of
available resources, leveraging OSGi in the enterprise was simply not
feasible. This is why, 18 months ago, OSGi was not a viable enterprise
technology. Yet, it was easy to recognize the potential, as well as the
momentum, which is why I made the following recommendations:
- Include OSGi in the Infrastructure Roadmap
- Monitor Product Evolution and Market Penetration
- Design for Modularity Now
Today, I have no doubt that we’ve crossed over to the Early Adopters
phase. I am starting to hear many more success stories from developers
who are leveraging OSGi. This is because platforms expose the
capabilities of OSGi to developers, tools have emerged that ease
development, and many third party frameworks have been “osgi-ified”.
Each of these advancements makes it easier and more viable to develop
applications that leverage OSGi. More than ever, we must heed the
recommendations above. OSGi continues to make its mark. If you’re an
early adopter, OSGi is ready and waiting for you.
Crossing the Chasm
Yet, the most
significant hurdle looms – crossing the chasm. There are a few different routes for OSGi. Let’s examine a few scenarios. First, some background.
JSR 294 is the standard that will define the module system for Java SE 7. Project Jigsaw leverages JSR 294 as part of the OpenJDK
project to create a simple module system for JDK 7. Officially, Jigsaw
is not part of Java SE 7. However, Jigsaw is going to be the reference
implementation (RI) for Java SE 7, implying Jigsaw is a logical choice
to become the JSR 294 RI. The OSGi Alliance does have members on JSR 294 (ie. Peter Kriens) to help ensure compatibility of JSR 294 with OSGi. If you’re interested, here’s a perspective from the middle of last year following JavaOne. Now, at this point, a few things potentially happen that affect the future of OSGi and Jigsaw.
- Recently, JSR 294 291 was marked as inactive. Alex Buckley commented
that this was only because of a process flaw in the JCP. A JSR is
marked inactive if it hasn’t produced an early draft for 18 months. He
assured the community that JSR 294 is alive and well. Yet, possibly
it’s a sign that Oracle isn’t behind the project, especially since they
have leveraged OSGi in some of their products, though they have been
quiet about OSGi since they announced their acquisition plans. With the
death of JSR 294 goes the death of Jigsaw. So, Jigsaw dies, and Oracle
throws their weight behind OSGi. OSGi becomes the runtime module system
on the Java platform. - JSR 294 inactive status truly is a snafu in the system. The JCP
delivers JSR 294, for which Jigsaw is the RI. Momentum builds around
Jigsaw and it becomes part of Java SE 7 implementations. OSGi is
relegated to niche markets (Eclipse RCP, home appliances). - The second scenario plays out, yet there are flaws in the specification and Jigsaw’s implementation that prevent its adoption. Neil highlights a few of these. In the end, OSGi is proven to address these shortcomings, and OSGi emerges as the de facto standard module system.
- JSR 294 does in fact ensure compatibility between Jigsaw and
OSGi. They can be used interchangeably. Everyone goes home happy.
Doubtful!
Try playing out your own scenario. Either way, all paths lead to a module system on the Java platform.
And certainly OSGi has a significant headstart.
But What If…
Wait a minute, though. Imagine that Java 7 never
gets launched as a JSR, is instead a proprietary implementation from
Oracle/Sun who tries to monetize Java 7. The other vendors decide to
boycott Java 7 and the world sticks with Java 6. Let fragmentation of
the Java platform commence. A dire scenario indeed.
Yet a plausible scenario, as well. There is no JSR for Java SE 7, meaning there is no specification nor technology compatibility kit (TCK). A recent article in SD Times
points out that there have been no new JSR submissions since Oracle
announced their decision to buy Sun. Likewise, no JSRs have entered
early draft review. So what exactly are Oracle’s plans? Well, it’s
possible we’re about to find out. On January 27th, Oracle is hosting a webcast where they intend to announce their plans. And as Mitch points out, Ellison certainly doesn’t want any distractions hanging around as the big race approaches.
So it may come down to this. The future of OSGi, Jigsaw, and modularity
on the Java platform comes down to the direction that Oracle intends to
take Java technology going forward. Of course, their decision will have
a tremendous impact on the entire Java ecosystem. We should have direction sometime soon. Time to set sail!
Leave a Comment
You must be logged in to post a comment.
