Community Begins Reviewing Java Module System (JSR 277) Early Draft

• A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.
• A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.
• A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
• Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
• A set of support tools, including packaging tools as well as repository tools to support module installation and removal.

Discussion on the JSR has began on JavaLobby.org:

...You add modules into the repository and just launch the module you want. If all dependencies (including version) are found, you app is started. To get this working you need to do some bookkeeping and I really hope that I will not have to do this manually because the maintenance of this is not a joy (same for OSGi). The JSR is NOT about hot deployment ... and for me that's a shame. All in all I thing that the jsr represents a very little progress but a progress nonetheless...

Matthias Ernst's first impressions:

• there are examples and scenarios for a number of use cases
• J2SE is expected to become modular itself - whatever the implications are for standards. Au revoir -Xbootclasspath?
• modules and their containing repositories are fully reflected at runtime.
• the specification predicts that JDC 4670071 bug will finally need fixing
• the syntax for module definitions is weird. It resembles annotations but not quite. Then, in a different section, using XML for URL repository descriptions seems ok for the EG.

So far, matters related to language specification have been in conservative, if not too rigid hands, so I expect this spec will be consistent. It's hard to judge how much easier or more complicated developers' lifes will become. According to section 2.18 the authors "anticipate many higher level tools and frameworks will build upon the module system to provide greater convenience and ease of use.". Let's hope so.

On his blog 277 expert group member Xavier Hanin writes that he thinks this JSR is something that will really change how developers develop applications and libraries. A true module system will allow the packaging of applications or libraries into modules.

Perhaps not unexpectedly the Peter Kriens of the OSGi Alliance does not write a favorable review:

...The ambition level of JSR 277 is significantly lower than where the OSGi specifications are today, even way lower than we set out in 1998. In a way, for me the JSR 277 proposal feels rather toyish. The Expert Group took a simplistic module loading model and ignored many of the lessons that we learned over the past 8 years. No built in consistency, no unloading, no package based sharing. Maybe we wasted a lot of time or solved unimportant problems, but I really do not think so. It would be ok if they had found a much cleaner model, well supported by the VM, but it is clearly not. Their model is based on delegated class loaders, just like the OSGi framework minus 8 years of experience. Ok, I am biased, so let us take a closer look. Though just a warning, the following text is utterly boring unless you are handicapped with a deep interested in Java class loaders... Wasn’t there anything I liked? Well, I like the idea of the repositories. The OSGi framework maintains the repository internally with its installed bundles, it left external repositories outside the specification by standardizing the installation API. Repositories allow the framework to download or find modules just before activation. This is an interesting model, pursued by Maven and the OSGi Alliance with OBR...