You are viewing robilad

Previous Entry | Next Entry

The JSR 277 early draft catches the worm


Let's assume that JSR 277, the one with the modules, has a spec lead who is really into communicating with people, figuring out where the wind blows and all that soft stuff. Then he'd be able to judge that the reception of the Early Draft of the module proposal didn't go down so well so far. And he'd contemplate how to fix that.

I am not the JSR 277 spec lead, nor do I work for Sun, but here's a handful of suggestions anyway, that may help improve the perception of a future JSR 277 'late' draft, or whatever the next step in the JCP process is called.

1. The spec lead should consider using the public jsr277-eg mailing lists for the expert group communication. There is no single post to the mailing list tracking CVS commits, suggesting that the Early Draft has been pulled out of thin air. That's not very reassuring.

There are no mailing list posts on the other 5 mailing lists either, except for one cautiously wondering what is going on. The spec lead may want to grace that query from last February with a reply, now that an Early Draft has been published. Or provide regular updates on this JSR's progress. Or post anything, actually.

2. The spec lead should consider using the "documents and files" web space at the public jsr277-eg site to put the Early Draft up for download. I have filed a bug report in the issue tracker for that, as a small reminder.

3. The spec lead should consider getting JCP.org's web site updated to reflect the current status of JSR 277. The front page makes no mention of JSR 277 being in Early Draft state. In fact, the first public announcement of the Early Draft came from a blog by Ivy developer Xavier Hannin, who is, oddly enough, not the spec lead for JSR 277. To add to the confusion, the spec lead's own blog has remained silent over the past 5 (in words: five) months.

Not using such obvious small ways to improve the communication between the expert group of JSR 277 and the rest of Java developers outside JCP's NDA walls will harm Java by both ignoring the needs of the Java community, and allowing ignorance to be used to easily dismiss what could/should/would be a useful JSR once it's done. I think that JSR 277 is too important to let the institutionalized distaste for open communication with the actual Java community at the JCP kill it off. In particular given that the competing, existing, presumably equivalent-or-better technologies, like OSGi, Maven, Ivy etc. don't suffer from that social problem.

Doug Lea has successfully demonstrated with JSR 166 that a core J2SE JSR does not have to wear the stigma of arrogance, and can be successfully driven to conclusion by embracing open communication with the Java community. The JSR 277 spec lead should not be afraid to emulate that approach.

3. The spec lead should consider changing the license covering the Early Draft. The current license has the text

The grant set forth above concerning your distribution of implementations of the specification is contingent upon your agreement to terminate development and distribution of your "early draft" implementation as soon as feasible following final completion of the specification. If you fail to do so, the foregoing grant shall be considered null and void.

That means it's rather pointless to try to implement the draft, since one has to throw away ones own code as soon as the specification is completed. Discouraging implementations of a JSR is a good way to avoid getting qualified feedback during the drafting process, but I don't think that should be a spec lead's goal.

In particular, I believe JSR 277 could profit from feedback, given that the problems it tries to solve (associating metadata with source code & binaries, repositories, component deployment, native code deployment) are not exactly novel, and have been successfully attacked by other efforts both inside the 'pure Java' community, and outside it. I'd boldly guess that writing 'bridge' implementations between whatever is in Early Draft and existing approaches could help iron out problems in the draft, as well as provide some way to explore and verify the usefulness of the approach outlined in JSR 277. But why bother, if one has to throw it all away?

Anyway, JSR 277 seems to have so far successfully managed to avoid soliciting feedback from those developers that could profit most from a built-in module system for Java: those already packaging Java modules for deployment in various operating system distributions. A lot of the problems JSR 277 tries to address seem to have been already tackled in JPackage, Debian, Gentoo, Fedora and other efforts without the need to modify the Java programming language to introduce new keywords, like JSR 277 apparently has to (nevermind OSGi and other, Java-specific efforts). Nevertheless, the expert group for the JSR apparently does not include persons experienced in that area. Neither does it include anyone from gcj, who actually have looked into binary compatibility and class lookup issues for natively compiled code written in the Java programming language, despite JSR 277 apparently trying to address that problem space.

Of course, one could say that they didn't ask to be on the expert group, in the first place. But after reading that OSGi's Peter Kriens, with 8 years of experience with OSGi, was not seen as fit by the spec lead to make the cut into the expert group, and the ridiculous issues with NDAs plaguing the JSR over the past year, the question for independent developers trying to help make Java better via JSR 277 would be: why bother trying at all if you can't talk about your work freely, and are likely to get rejected anyway, even if you actually have a clue about the problems that the JSR tries to solve?

That's not a good message for the JSR 277 to send out, if the spec lead hopes for the JSR to set a standard that the community will embrace over the half dozen of other solutions, like OSGi, Maven, Ivy, etc. As long as the spec lead choses to remain silent on the various social, communication and management issues around JSR 277, that 'JSR 277 is yet more NIH from Sun' message will only get louder. If even flag-bearers of the JCP like Cameron Purdy are saying it, I would expect someone to notice that and do something about it.

4. The spec lead could try to come up with good, clear answers to these two simple questions:

a) Why didn't OSGi/Maven/Ivy/NetBeans Modules/JAR Manifests/whatever-else-is-there become the one true way to deal with modules in Java yet?

b) What does JSR 277 do so differently from these existing efforts to have a chance of succeeding further than they have?

Update: If you came here via java.net (thanks for linking over here, Chris, yes, it's me), you may have missed that the spec lead, Stanley Ho wrote a blog post about JSR 277 today back on java.net as well.

If you want more transparency on this particular JSR, it sounds like a good place to point that out politely.