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:
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.
- 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.
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.
Step in the right direction
- 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
JSR 277 == JSR 47?
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?
Tangosol Coherence: Clustered Shared Memory for Java
Re: JSR 277 == JSR 47?
Re: Great news!
Re: JSR 277 == JSR 47?
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.
Re: JSR 277 == JSR 47?
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.