Yesterday, Mark Reinhold posted the first public draft of the future of modularity in Java. As it is a draft, there are a handful of issues that still need to be agreed on - but it represents the consensus of what modularity in Java should look like. And with IBM being involved, there's more emphasis on interoperability with OSGi than there has been in the past.
Since the last bundle.update, a number of interesting events have occurred in the OSGi and modular Java space. JSR 294 has been (automatically) marked as inactive, the Enterprise Expert Group has released draft 4, WebSphere will allow direct running of OSGi applications and upcoming OSGi conferences have early bird discounts and call for speakers finishing soon.
It's been a month since OSGi 4.2 was released. What's been happening in the OSGi space since then?
Over the past month there has been a lot of debate on the current state of the Java Modularity working group (JSR 294). Although the JSR tries to find common ground between different module systems (notably Sun's Project Jigsaw and OSGi), the current set of proposals are overly complex and introduce the world's first concept of a meta-module system. Can the Simple Module System save JSR294?
Peter Kriens, technical director of the OSGi alliance, gave a presentation on the upcoming OSGi 4.2 release at the UK OSGi Users Group. The event was recorded, and the video is now available. OSGi 4.2 is expected to be released to the public by the end of August 2009 and includes a number of new features.
Long plagued by controversy, Sun's attempts to modularise the Java platform saw more positive reactions from the JavaOne crowd.
In this article, Lukas Krecan, introduces the reader with some basic concepts of modularization, gives a roundup of some Java module systems and deals with how Project Jigsaw is connected to the upcoming Java 7.
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. Is this the death of JSR277?
Last month we asked whether Sun were listening about OSGi; at JavaOne, it was clear that many others have. Not only are all of the main J2EE engines now OSGi-enabled, but Spring launched their OSGi-based Spring Source Application Platform. Fortunately, a number of positive changes have occurred behind the scenes with JSR277; read on for what's been happening.
A new proposal, iJAM, has circulated on the JSR-294 and modules-dev mailing lists suggesting some changes to the logic supplied in the strawman proposal for JSR-294 'superpackages' and receiving some positive feedback.
OSGi is a Java modular development specification. OSGi is used in a wide variety of applications, from mobile phones to enterprise servers and the Eclipse IDE. In this interview, Peter Kriens explains where OSGi came from, what sorts of applications it's useful for, integration with Spring, the JSR 277/294 debate, and the future of OSGi.
The OpenJDK project has released early an access snapshot of the Java Module System (JSR 277) and Improved Modularity Support (JSR 294). JSR 277 addresses modularity from a deployment unit perspective. JSR 294 addresses modularity from a development perspective, introducing a new language construct, called superpackages, for information hiding.
Glyn Normington has written an overview of Java modularity covering JSR 277, JSR 291 and JSR 294. He describes how each is different and adds value, and later responds to the question of why we need modularity support in the JVM, as opposed to custom classloaders (like OSGi).
The BeJUG website recently released a presentation on the Java Module System (JSR 277) by spec lead Stanley Ho. The presentation covers the driving forces for JSR 277 such as classpath and jar hell. The online presentation also includes over five minutes of QA time after the presentation.
JSR 291 Available for Public Review JSR 291 has been made available for public review. JSR 291 is also known as OSGi core spec R4.1.