Login / Sign Up
process management service oriented architecture soa blog posts
Contributed on January 21, 2010
1.2k

Java Modularity - Time to Set Sail

Kirk
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!