Why is Sun inventing another module system when everyone has standardised on OSGi?

Question

Sun is putting a lot of effort behind modularising the JDK in the form of Jigsaw, and insinuating that it should be the module format of choice for other Java developers as well. The only notable player who is using this is NetBeans (and derivative applications).

On the other hand, the industry has standardised around OSGi, with all of the major application vendors basing their runtimes on the module platform, even Sun's own Glassfish. There's even a port of NetBeans to use OSGi as the module system instead of NetBeans own modules. Even Maven is working towards becoming an OSGi runtime.

Is it just NIH, licensing, or another reason?

Answer 1

Citing http://blogs.oracle.com/mr/entry/jigsaw:

OSGi is not at all integrated with the Java language, however, having been built atop the Java SE Platform rather than from within it.

This last problem can be fixed. Sun plans now to work directly with the OSGi Alliance so that a future version of the OSGi Framework may fully leverage the features of JSR 294 and thereby achieve tighter integration with the language.

(...)

If and when a future version of the Java SE Platform includes a specific module system then Sun will provide a means to migrate Jigsaw modules up to that standard. In the meantime we’ll actively seek ways in which to interoperate with other module systems, and in particular with OSGi.

Answer 2

The rationale behind project Jigsaw and how it relates to OSGi was outlined by the Jigsaw team in Java Posse Podcast 259.

These projects do not entirely overlap and the introduction of Jigsaw does not sound the death knell for OSGi - the scope of OSGi goes beyond anything Jigsaw will attempt. There's much more to Jigsaw than the OSGi team is in a position to provide (language, class and JVM implementation changes). The design of OSGi is based on the current JVM design - the changes to the JVM will benefit everyone.

At least, that is my take from what I've read.

Answer 3

Excellent question. My understanding is that in some areas OSGi goes way beyond that which is necessary for JVM modules (with all the corresponding complexity that brings) whilst in other areas it doesn't go far enough. So there's a lot of overlap between them but perhaps not enough.

See this blog entry

Answer 4

Check out the JavaPosse interview with Mark Reinhold on the subject.