Following up from an earlier post about modularising the JDK (which InfoQ covered earlier), Mark Reinhold posted the announcement of Project Jigsaw as part of the OpenJDK. From the announcement:
In order to modularize JDK 7 in the next year or so, and in order better to inform the work of JSR 294, Sun will shortly propose to create Project Jigsaw within the OpenJDK Community.
This effort will, of necessity, create a simple, low-level module system whose design will be focused narrowly upon the goal of modularizing the JDK. This module system will be available for developers to use in their own code, and will be fully supported by Sun, but it will not be an official part of the Java SE 7 Platform Specification and might not be supported by other SE 7 implementations.
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.
The stated goal - to modularise the JDK - should be achievable, especially since Apache Harmony has already demonstrated that the JDK can be modularised (and using OSGi manifests). But the goal is more interesting for another reason; it's being done outside of the JCP
The lack of visible progress, and the behind-closed-doors implementation effort that was JSR 277 meant that it was very difficult for others to be involved or influence the development. Often, that lead the standard down the wrong path, focussing too much on implementation details and not enough of an interoperable standard. Not only that, but the standard was an after-the-fact write-up, which meant that by the time it came to fix problems (such as odd version numbers) it was already too late. According to the post, JSR277 is 'on hold' but in practice it's dead.
Splitting JSR294 (previously superpackages, now module) back out of JSR277 is also a great move; this will introduce language changes that will allow modularisation to happen independently of any particular modularisation process.
What is also encouraging from the post is the realisation that OSGi is already a de-facto standard that's used for modularisation, and that co-operation is a good thing. That doesn't necessarily mean it will be based on OSGi though; in fact, it's suggesting that OSGi come together with it rather than the other way around:
OSGi If JSR 277’s JAM module system is an unsuitable foundation for modularizing the JDK, what about the OSGi Framework? This module system is reasonably mature, stable, and robust. Its core has even already been implemented within a Java virtual machine, namely that of Apache Harmony. 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.
I'm sure that it will be possible for a future OSGi standard to use JSR 294's modules, although there are some changes suggested. Either way, next week's Modularity in Java talk at Devoxx 08 should be an interesting revelation of the future of Java.