Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Java Modularity - OSGi and Project Jigsaw

06.12.2009
| 23133 views |
  • submit to reddit

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:

References
Published at DZone with permission of its author, Kirk Knoernschild. (source)

Comments

Les Stroud replied on Fri, 2009/06/12 - 4:30pm

"Additionally, there is no guarantee that Jigsaw and OSGi will be compatible module systems." I believe that if you go back and listen to the speech he rather directly says that it will be interoperable with existing module systems.

I don't have a dog in this fight, but OSGI seems to be the right idea, but implemented without the ability to make both language and jvm changes. Frankly, OSGI is combersome, there is a lot of configuration and non statically checked text. So, it begs the question what would OSGI look like if it could change the language and the vm and were designed from scratch with that in mind. So, from my perspective Jigsaw is learning from the lessons that OSGI has earned and is refactoring it into a simpler more easily understood mechanism.

Maybe I'm missing the boat since I don't have the details, but the jigsaw demonstration was something that we all want.

Liam Knox replied on Fri, 2009/06/12 - 6:01pm

As far as I recall Mark was clear on concerns regarding partitioning of core jdk packages ( 1-1 / 1-many) to modules and that OSGi was at a higher level than that needed in modularising the JDK. How that pans out I have no idea. Interop is the main point. Personally in my field I have seen little need or adoption for OSGi. I can understand the benefits but in a very rigourously versioned, release controlled environment I cannot see it adding much.

Ryan Developer replied on Sat, 2009/06/13 - 8:02am

I don't know anyone who uses OSGi and a poll at my local JUG shows that only a few people are even looking at it.   It's not clear if they are waiting for the dust to settle (like BluRay vs HD-DVD) or if not everyone feels they need it.   I am waiting for the dust to settle, and will use whatever is built into Java SE platform as long as it is JCP approved and implemented in other JVMs too.

I don't think the difference between Jigsaw and OSGi are pure politics.  I think OSGi is a bunch of hacks around ClassLoader problems, and Jigsaw fixes the problem instead of patching on top of it.

 

Augusto Sellhorn replied on Sat, 2009/06/13 - 8:25pm

Good to see that people are interested in this topic.

 As I pointed out in my blog post (linked to at the bottom of this article), there is a plan for supporting multiple module systems. As a matter of fact, if you look at the metadata for module-info.java you'll notice a keyword saying what module system is being used. Also, there's a provision for allowing multiple versioning mechanisms based on whatever module system you are using.

As for Jigsaw being "JCP" approved, well ... there is no Jigsaw JSR, it's being done as an implementation detail of Java/JDK 7. There is JSR 294, but Jigsaw is NOT a reference implementation of it (even though it seems like it is, this gets confusing).

 As for nobody using OSGi, well ... Eclipse uses it and all plugins of Eclipse have to use it so it is a relevant technology. You are seeing more and more appserver and ESB vendors using it, to the point that even Glassfish hired the main Apache Felix guy to help them integrate OSGi in Glassfish. So it is a technology that has been around for a while, and it is being used. If more people are not using it, it's probably because ; a) it's not a standard Java subsystem (like Jigsaw will be in 7), b) Many people are not used to modular programming in the first place.

 

Robin Bygrave replied on Sun, 2009/06/14 - 8:14pm

My understanding is that standard OSGi doesn't support AOP.  Hence things like "Import Scope" in spring DM server.

So if you want to use AOP enhancement (for ORM / @Transactional etc)... then you currently need to use vendor specific enhancements to standard OSGi.

Would be interesting to know what is happening in that regard.  Anyone know?

James Walker replied on Sun, 2012/11/11 - 12:59pm

 Currently in progress, this JSR will define the language and virtual machine changes that will be made to support modularity on the Java platform read more

Zem Karlos replied on Mon, 2012/12/17 - 9:59am

 
A good informative post that you have shared and appreciate your work for sharing the information. Got some interesting information and would like to give it a try. Appreciate your work and keep sharing your information.Houston dentist

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.