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.sun.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

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 bringsm 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 3

One feature is missing in OSGi. It does not support modules that are subsets of packages. The export is done on the package level.

Package subset modules are the only way to cut the Gordian knot of JDK dependencies. And a nice hint why you should keep your code clean of circular dependencies.

Over the years, however, this style of development can lead to unexpected connections between APIs—and between their implementations—leading in turn to increased startup time and memory footprint. A trivial command-line “Hello, world!” program, e.g., now loads and initializes over 300 separate classes, taking around 100ms on a recent desktop machine despite yet more heroic engineering efforts such as class-data sharing. The situation is even worse, of course, for larger applications.

Edit: I was wrong. OSGi does support split packages.

Answer 4

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 5

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