Skip to main content

The Bones of an Idol

Posted by editor on October 23, 2006 at 7:55 AM PDT

Picking through the JSR-277 draft

Well, the public review period is supposed to be just that: a time to present an early draft of a JSR to the public for review, commentary, and criticism. Writing for, Peter Kriens has put together a fairly thorough shakedown of the early draft of Java Module System in a lengthy blog timply titled JSR 277 Review.

Summarizing the draft proposal, Kriens calls it unambitious, saying the ambition level is lower than when OSGi started work on similar problems in 1998, and furthermore, it doesn't learn from OSGi's experience:

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.

Kriens' commentary is significantly involved with class-loading, which he says should be the responsibility of the module framework. He points out that when your dependencies have their own dependencies on different and incompatible versions of other modules, these will show up as hard-to-trace ClassCastExceptions. He also notes that there is a "fan out" problem which results in importing hundreds of barely-related or even unrelated modules, as a result of dependencies of dependencies of dependencies being resolved.

His critique closes with a pretty harsh conclusion:

JSR 277 takes a simplistic view of the world, ignoring many real life problems: consistency, optionality, split packages, etc. The only way this EG can pass its final review is lack of attention for detail of the Executive Committee or alternatively, serious muscle power of SUN. JSR 277 is a missed opportunity for Java. I do not doubt that this specification will end up in Java 7, but it will further fragment the Java world for no technical reason. Not only is this specification impossible to implement on J2ME any time soon, it will also leave the many OSGi adopters out in the cold. Why?

Wow. That's a pretty thorough denunciation. But is it accurate, and fair? What do you think? The JSR-277 review runs through November 13, so this is the time to read the spec and figure out if it's the right solution to the right problem.

Also in Java Today,
Dr. Dobbs' Journal takes a look at support for Java EE 5 among various vendors in App Server Powers Race To Embed Java EE 5 Support, reporting that "top vendors are moving quickly on Java EE 5 support. By early next year most will have compatible updates shipping." The article also notes how GlassFish not only offered an implementation concurrent with the release of the EE 5 spec, but may also be helping other app servers to get their EE 5 implementations out sooner.

Meet Scott Violet, Architect for the Swing Toolkit Team at Sun Microsystems is the latest in the SDN series of interviews with key Java platform engineers. In the interview, Scott talks about developing visual effects with Swing, the beans binding effort that he's heading up as the JSR-295 expert group lead, new desktop features in Java SE 6, and more.

This week's Spotlight is on
the Current CMS project, which offers a content management system (CMS) that is the product of nine years of development, originally developed with flat files and perl, but later migrated to Java. Current CMS is a multi-user CMS with workflow, versioning and publishing capabilities. It includes a generator that prepares scaffolding including Java model and view classes, JSP, SQL create and alters... all based on simple XML configuration files. The project was also the subject of a recent feature article.

James Gosling talks up his multilingual documentation project in today's Weblogs.

Translation segmentation, he writes:
"I've been hacking furiously on, the community translation site for java documentation (even if you're not interested in translation, it's still an interesting way to read javadoc). There's been a pile of bug fixing. The biggest change that people using the site will notice is that when you volunteer to do translations, it breaks large chunks of text down into more manageable segments.