Alex headshot

AlBlue’s Blog

Macs, Modularity and More

JSR294: Knee-jerk reaction?

Java 2006 Eclipse

Sun has recently announced JSR294, which aims to provide Improved Modularity Support in the Java(TM) Programming Language. From the description:

We plan to extend the Java programming language with new constructs (tentatively called "superpackages") that allow hierarchical modular organization. We expect these constructs to be supported at the virtual machine level, through modifications or extensions to the JVMs access control rules.

Interestingly, they think that will impact not only the Java language, but also the Java VM as well. As Elliotte Rusty Harold put it, "If inner classes and generics did not require VM level changes, this proportionately smaller change shouldn't either?". Perhaps this is just a blanket protection in case they need to do so in the future. I personally like the way that the JSR links to his blog for its details :-)

It seems that this might be a bit of a knee-jerk reaction in response to the OSGi bundling mechanism. For those that don't know, the OSGi bundle mechanism is the infrastructure that underlies Eclipse (and other systems), and allows the application to be partitioned into different modules, very much like JSR294 is hoping to achieve. Except instead of requiring changes to the language, it's a bundling issue. Tools (like Eclipse) manage the project dependencies between these bundles, and you only expose to your clients what you want to (hence the collection of .internal. packages in the Eclipse codebase). It's also a good way of enforcing the codebase to be suitably partioned, both from a design and also project layout mechanism.

Having said that, there's no reason in the future why the OSGi couldn't utilise the extensions in the JSR in the future. It probably won't, primarily because this is a Java Dolphin proposal (so wouldn't work on anything before) but also because the OSGi works across all layers (from CDC1.0 up to J2EE 5).

I also think it's good because the more people that are aware of partioned Java delelopment, the easier it is for them to understand both the Eclipse plugin model and the OSGi architecture upon which it is based :-)