The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Alex Blewitt on Dec 03, 2008
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.
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Monitor your Production Java App - includes JMX! Low Overhead - Free download
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
No comments
Watch Thread Reply