The Java Standards Annoyances session at OSCON 2011 looks like fun. I wish I could be there.
If I were there, after first expressing congratulations mixed with condolences to Ben Evans and the London Java Community on the election to the EC, I'd probably say that the most important part of building standards is knowing when and what not to standardize. The PMO measures success quantitatively, in terms of numbers of JSR stage transitions, but the inevitable result has been that a lot of the JSRs that made it to final release are junk that should never have been accepted in the first place. The EC actually did one useful thing during my time as a member: It rejected the PFD of a (well-intentioned) JSR that was not ready for prime time.
So talk of "streamlining" the process makes me nervous. I wouldn't want to make it easier to introduce garbage, and I don't trust the EC to be a responsible gatekeeper, nor do I trust the JCP as a whole to provide high-quality feedback during public review; there's too much noise, and it's too easy for a spec lead to ignore substantial criticism.
There are good JSRs. Naturally I think the JSRs on whose EGs I have served are good ones, the most recent being JSR 334 ("Coin"). But I think the enthusiasm and energy of the community should be directed more at building great libraries and frameworks than at getting them accepted as standards.
2 comments:
Hi Tim,
Thanks for your contribution to the debate (and your good wishes) - if you don't mind, there are some points here that I'd like to throw into the mix at the session itself (and it's a shame that you aren't around to join us!).
To your point about streamlining the process - the changes in JSR 348 are intended to change the JSR process pipeline in such a way that standards need to progress faster. It isn't about changing the gates which exist in the process, rather shortening the amount of time that JSRs can exist without making tangible forward motion.
This is intended to solve the problem that we have now - a large number of JSRs which "seemed like a good idea at the time" but for which the moment has now obviously passed.
The LJC's central aim within the JCP is to try and encourage more people who are actually going to be the end users of the standards to get involved at EDR stage. We also want to encourage spec leads to not be afraid of "EDR early, EDR often".
I'd also say that I don't necessarily see the activities of standardisation and of "making great libraries" as in tension with each other. Sometimes innovation runs quite a way ahead of standardisation, and then there's a second phase of standardisation / commoditisation as what was innovative is reconverged into standard practice. At that point the innovators need to pay some technical debt to join the converged world, but that's part of the cost of innovation.
So where individuals and communities want to focus their effort is, for me, simply a matter of what particular itches they feel like scratching just now.
After all, trying to standardise an area without a decent corpus of technical practice to draw upon is bound to be fraught with problems.
Thanks,
Ben
I think the key thing to avoid dud JSRs is to increase participation at the early stages of a JSR by a wider range of developers/users.
I believe that JSR-348 will help a great deal by removing transparency barriers and other procedural roadblocks. However, I think there are also many other barriers to JSR participation (some technical, several social). I guess our concern today is that very few out of the ~9 million Java Developers know about, or get involved in the process. JSRs like JSR-310 (Date and Time) should be *crawling* with 10's if not 100's of enthusiastic volunteers - after all developers have been complaining Date/Time for years!
Not many JSRs get the early support that we'd like (project Coin was a great exception to this) and the reasons as to why this occurs could fill a separate novel, but I think we can at least change the social culture around them
For example, could user/technology groups hold a night where they talk about a JSR like 310 (when it was still fairly young) and run a workshop, trying out code and giving feedback to the EG? I think they could. I'm really hoping we can make that happen (the Java 7 launch party gave me great hope that this is possible). SouJava and ourselves will be trying to get the JUG community and beyond getting involved in JSRs (we have plans for an 'adopt a JSR' program), wish us luck, we have a lot of work to do :-).
Post a Comment