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

by Scott Delap on Oct 19, 2006 |
The early draft of JSR 277 was recently released. Community review is open until Nov. 13th. This JSR seeks to improve the distribution of Java applications by defining a distribution format and a repository for collections of Java code and related resources. More specifically the specification description lists the following target areas:
  • 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

...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...

InfoQ earlier this year covered broadening industry use of OSGi.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Module Hell? by Chris Gardner

Hopefully in a few years we won't be uttering "Java Module Hell".

Great news! by Emmanuel Pirsch

I think this is great news! After a quick read, I found a few annoying things (module definition are a bit too verbose - see my blog for details), but it will be a great improvement over the current situation.

Step in the right direction by Ben Murphy

a couple of things i didn't see(maybe i skipped over too fast)

- strongly named modules similar to .net. i can see issues because some crazy developer has decided to make their own version of a common library and stick it in the global repository. though, you could just ship all your dependencies and have a Main class that sets up a private repository and then boots your app.

- a way to specify you want your own private instance of a module. this would seem useful for a module that has static configuration. (logging?)

Re: OSGi / JSR 277 ... Not Invented Here Syndrome by Scott Delap

JavaLobby has an interesting commentary on the overlap between 277 and OSGi claiming Sun has a good dose of not invented here syndrome.

JSR 277 == JSR 47? by Stuart McCulloch

It does sound like NIH - will this be a repeat of the java.util.logging / Log4J saga?

See also Intel's comments during the original ballot for JSR 277:

1. There are no initial EG Members listed in the JSR (very unusual). The EC and community use this information to judge the interest level, fairness in representation in the EG and whether the EG has the expertise it will need to complete its work. The Sun Ballot statement pledging a diverse group and opening the group to EC members is a positive move. However, it does not replace being able to see a representative set of EG members when the JSR is being considered for approval. This should not be considered a precedent for leaving out this information. On a less important JSR, we'd vote "no" if this information is missing.

2. We found the JSR text inappropriately negative about OSGi and welcome the Sun Ballot statement correcting that. We expect the group to contain OSGi experts and that, after the EG determines requirements, OSGi will be given fair consideration by the EG in light of the requirements.

Re: JSR 277 == JSR 47? by Cameron Purdy

Very concerning. Sun needs to get someone _from_ OSGi to drive the spec, and maybe the spec ends up being OSGi. Frankly, I'm a lot more comfortable with the quality of OSGi (from the specs and the proof via implementations) than I am with a new "from scratch / NIH" Sun initiative.


Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Re: JSR 277 == JSR 47? by Xavier Hanin

JSR 277 tries to get something which would be the result of the experience from several actors involved in the module area, thus there are already several person from OSGI involved in JSR 277 (including Glyn Normington, who is also spec leader for JSR 291). I personnaly think it's a good thing to have several point of view in this JSR, and not only OSGI members one. The downside is that it make things slower, but I think it's worth the time it takes. My 2c.

Re: Great news! by Stephen McConnell

Emmanuel: I aggree with your sentiment ("..great news"). I've responded on your blog to the items you mentioned as annoying. If effect I think the issues you mentioned will end being non-issues simply because of (a) tools support in the JDK (not least of all javac), and (b) APIs then will let you add in third-party tools (and some of us are already thinking about added value solutions in the areas of module related tools).

Re: JSR 277 == JSR 47? by Stephen McConnell

At the time of the JSR 47 the Log4J project did not have a clear client API. At the same time a number of other logging solutions were prevelant - solutions that presented significant advantages over Log4J from some points of view. If JSR 47 had happended a year or two later then parhaps a nonimally standard API would have emerged - but I have doubts (and I was involved in discussion on this subject with the concerned parties).

The end result of JST 47 is the java.util.logging package which was rapily incorporated into the broad spectrum of logging solutions (including Log4J).

Is JSR 277 == JSR 47? Perhaps in that it is addressing a core area of common concern - and area in which the types and numbers of systems that will be positively impacted are much broader than some people would have you belive.

Cheers, Steve.

Re: JSR 277 == JSR 47? by Stephen McConnell

Cameron: JSR 277 is addressing runtime deployment of modules - this is a subject that has a tangential relationship OSGI only in that OSGI have had to address this subject as part of an overall component deployment platform. If you read the OSGI R4 spec and you read the 277 draft spec and you dig down into the subject of modularization and classloading management - for me, it's a no-brainer. The 277 solution simply a lot cleaner and a lot closer to my needs. Furthermore, ... I don't see anything in 277 which could not be used constructively with OSGI implementations.

But are technical arguments relevant here? Or are we actually talking about fear of OSGI brand fragmentation as a result of the introduction of deployment solution addressing broad requirements into the JRE (that go way beyond OSGI and address common needs from hundreds of other solution providers that are not met by OSGI)?

I would suggest to the OSGI community that they stop the bitching and moaning and move towards constructive engagement. The draft spec is good (and maybe its because there are a couple of OSGI people of the expert group). What I want to see is work on an RI. I want to see good tools and validation of extension mechanisms. I would like OSGI to bite the bullet and look at 277 as an opportunity and contribute as such. OSGI needs to make a choice - engage or be the subject of stories of bitter and twisted individuals in times past.

Cheers, Steve.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss
General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.