Java Modularity - OSGi and Project Jigsaw

I’ve had some time to reflect on the sessions pertaining to Java modularity that I attended at JavaOne. This topic can be pretty confusing, so let’s take some time to clarify a few things.

The JSRs

Initially, there were three primary JSRs surrounding Java modularity - JSR 277, JSR 294, and JSR 291. Descriptions follow:

• JSR 277 - Also known as the Java Module System, JSR 277 was an alternative module system being proposed that would have provided similar, though less, than what OSGi currently provides.
• JSR 291 - Proposed by IBM around 2006, JSR 291 defines a dynamic component model for Java SE. This JSR brought OSGi into the JCP. In general, this did for Java SE what JSR 232 did for Java ME.
• JSR 294 - Currently in progress, this JSR will define the language and virtual machine changes that will be made to support modularity on the Java platform.

Today, JSR 277 is inactive, JSR 291 is final, and JSR 294 is in progress. That makes it all seem rather simple. But things get messy pretty quickly. JSR 294 does not define a module system, it simply specifies changes to the language and VM that module systems can leverage. The intent is that module systems be built atop JSR 294. And today, there are two separate module systems for the Java platform - Project Jigsaw and OSGi.

The Module Systems

Many have heard of OSGi. It’s been around for over 10 years, originated in the mobile and embedded systems space, was popularized by the Eclipse foundation upon adoption for it’s plugin system, and is currently being leveraged by every major application platform vendor, including Sun’s Glassfish product. Jigsaw, however, is not as mature nor as well-known.

Jigsaw is an Open JDK project. The intent of Jigsaw is twofold - to modularize the JDK and allow developers to modularize their applications. While the Reference Implementation (RI) link on the JSR 294 homepage navigates to the Project Jigsaw homepage, Jigsaw is not technically the RI for JSR 294. Instead, Open JDK 7 is the RI for JSR 294, and as it happens, Project Jigsaw is an Open JDK 7 project. Certainly modularizing the JDK is a good thing. But it does beg the question - why not build atop the proven and de facto standard OSGi dynamic module system? The answer to this question is not entirely clear. What is clear is that Jigsaw revives JSR 277 outside the context of the JCP governing body.

In a JavaOne session led by Jigsaw proponent Mark Reinhold, he stated that Jigsaw addresses “requirements that aren’t met by existing module systems.” While I have to conclude that Mark was indirectly referencing OSGi, he wasn’t clear on what these missing requirements are. Additionally, there is no guarantee that Jigsaw and OSGi will be compatible module systems. While both may eventually leverage the language and VM features of JSR 294, it’s doubtful that modules developed using Jigsaw will be interoperable with OSGi bundles. Certainly, the Java community doesn’t need this fragmentation. Of course, the debate surrounding Jigsaw and OSGi may be a moot point with the impending acquisition of Sun by Oracle, who has invested significantly in OSGi with their Fusion middleware product line.

In general, OSGi clearly has a significant advantage over Jigsaw today. It’s mature and widely adopted across the industry, though Jigsaw has the inside track given it’s inclusion as part of the Open JDK 7 project and it’s sponsorship by Sun insiders. But it’s confusing why Sun is adverse to building atop the proven OSGi platform, and there are many questions surrounding modularity on the Java platform that deserve an answer. Notably, what requirements is Jigsaw addressing that OSGi does not? And why is Sun adverse to leveraging OSGi as the standard module system for the Java platform? Sadly, I suspect the answer to these questions has little to do with technology, and more to do with politics.

For more information on the debate surrounding Jigsaw and OSGi see the following references:

• Neil Bartlett’s enlightening synopsis of Jigsaw in this blog post titled Hope, Fear, and Project Jigsaw.
• Mark Reinhold’s entries introducing and explaining Project Jigsaw, titled The massive, monolithic JDK, The Modular Java Platform, and Project Jigsaw.
• Peter Kriens take on Project Jigsaw and JSR 294 in his blog posts titled, Project Jigsaw, Project Jigsaw #2, Project Jigsaw #3, and JSR 294.
• Eric Newcomer recently shared his thoughts on OSGi Standard Questions, and talks about Project Jigsaw.
• Augusto Sellhorn published an excellent review titled Classpath hell just froze over of Java modularity based on his experiences at JavaOne. He also includes references to additional resources at the end of his post.
• Peter Kriens also references Augusto’s blog entry in his post titled Classpath hell just froze over?, where he speaks about some of the problems with Jigsaw.

Kirk an industry analyst at Burton Group. For 15 years, I worked in the trenches on real software projects. I believe software development is an amazing profession. I take a keen interest in design, architecture, application development platforms, agile development, and the IT industry in general, especially as it relates to software development. I also enjoy experimenting with new technology, whether it be the the cool new framework or tethering my smartphone to my Mac via Bluetooth to get an internet connection. Kirk is a DZone Zone Leader and has posted 55 posts at DZone. You can read more from them at their website.