Monday, March 19, 2007

Background to Java modularity

Should Java have included modularity features from the start or is the kind of modularity really needed in Java rather different from that baked in to some other languages?

In 2003, IBM Research published a paper known internally as "modjava" but named "MJ" externally. The authors' approach was to create a static module system not dissimilar to the strawman for JSR 294 except that MJ was built from class loaders for ease of prototyping and didn't encompass versioning (although a couple of us refactored the internal MJ prototype to enable versioning).

Vernon Green and I then led a working group in IBM's Software Group Architecture Board on Java versioning and modularity which started from the MJ paper. Later we discovered OSGi and how that matched in many respects what the working group was looking for. I was given the task of taking our additional requirements into the OSGi R4 standards activity where I struck up a collaboration with Richard Hall who had a similar perspective based on his research work on the Oscar OSGi framework.

The real world requirements of versioning and dynamic modification of applications and supporting software without restarting the JVM have effectively forced Java to develop the new, and highly successful, OSGi technology.

It's interesting to speculate what would have happened if a static module system had been put into Java much earlier. My guess is that it wouldn't have bothered to address versioning or dynamicity requirements which only become crucial in the context of relatively large systems with continuous operation.

The JSR 294 Expert Group is just starting up, so this background suddenly becomes relevant...

3 comments:

Anonymous said...

"It's interesting to speculate what would have happened if a static module system had been put into Java much earlier.".

Indeed it is.

Glyn said...

Thanks Rob. Mono seems to have a module system based on assemblies with similar versioning rules to .NET assemblies. This appears to be at the opposite extreme to "DLL hell": you have to go out of your way to share versions where the importers' requirements are not identical.

Any links to technical appraisals of Mono's module system or versioning capabilities would be very interesting.

Rob Yates said...

Mono's versioning rules match those of .net. Policy files can overide the default behaviour of loading the exact version of an assembly that the program was compiled against.

There is also documentation on mono's GAC and friend assemblies are supported by mono's new gcms compiler.

Projects

OSGi (130) Virgo (59) Eclipse (10) Equinox (9) dm Server (8) Felix (4) WebSphere (3) Aries (2) GlassFish (2) JBoss (1) Newton (1) WebLogic (1)

Blog Archive