Tracking change and innovation in the enterprise software development community
Create REST
-enabled Web Apps
with Project Zero
from IBM.
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
InfoQ recently sat down with Peter Kriens of the OSGi Alliance to learn more about OSGi. Kriens discussed OSGi's origins in the mobile space, it's integration with Eclipse, the current integration work with Spring, and the future R5 specification. He also discussed the ongoing debate over OSGi and JSR 277, and gave his perspective on what an ideal solution would be for modularity at the JVM level.
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.
The expert group behind JSR 277 has been largely quiet despite questions from the community at large on its status and possible compatibility with OSGi. In recent weeks calls for information and criticism have become louder.
The Spring Dynamic Modules for OSGi project, formerly known as Spring OSGi, released version 1.0 today. InfoQ spoke with SpringSource CTO Adrian Colyer and Spring Dynamic Modules project lead Costin Leau to learn more about this release and what it provides for the Spring community.
Recently, Alex Blewitt described the Java Community Process (JCP) as dead, likening it to a headless chicken which "doesn't realise it yet and it's still running around, but it's already dead". This touched off a debate over the usefulness of the JCP and how much it will play a role in Java's future.
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.
The latest salvo in the discussion of JSR 277, JSR 291, and OSGi appeared last week in the form of a post by Glyn Normington, spec lead for JSR 291 and Expert Group member for JSR 277. He is concerned that the Expert Group has not been presented with a strawman yet and that the Expert Group will end up merely rubber stamping the strawman rather than discussing it in detail and making changes.
The debate over JSR 277 (Java Module System) and OSGi (JSR 291) is picking up steam again, with the JSR 316 (Java EE 6) submission restarting the previous debate about the overlap between OSGi and JSR 277. InfoQ has collected and summarized several viewpoints and arguments around this debate.
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.
