Blog Posts Process Management Service Oriented Architecture (SOA)

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.

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:

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:

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.

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

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples