Posted by editor
on April 19, 2007 at 7:39 AM PDT
Is "open from the start" the right way to develop a JSR? Also:
Java Today: Open JSR development, type inference for JDK 7, and JavaChecker
Feature Article: XQuery For Java, An Enabler For SOA
Weblogs: Multithreaded hashtable, network blocking and MIDlets, and does anyone still use JSP's?
Forum messages: Writing to stdin, http file upload, and JAI design concepts
Is "open from the start" the right way to develop a JSR?
So how should a JSR work anyways? More and more, this is becoming a hot topic for everyday Java developers, who want their concerns and desires incorporated early in the process, not late in the game when the final draft is being routinely approved, or after the fact. As the ideas for JDK 7 come together, we've already seen vigorous debate about proposed concepts like closures, properties, a module system, type inference (which we'll get back to in a minute), and more. For some, it may be "buyer's remorse" over generics, a feature still somewhat controversial two versions after its release, and the better part of a decade after its initial proposal . Whatever the reason, more and more developers are learning to get involved early.
And maybe that's part of the reason we're also seeing a questioning of how a JSR expert group carries out its work. We ran a blog several months back -- sorry, I can't find the link right now -- that decried the model of an expert group doing both its original research into a problem domain, in private, and then proposing a Java standard for it, all in the scope of one JSR. Would bad JSR's have been headed off sooner if there had been more public visibility into the expert groups' work earlier, while they were working the problem and before the early draft review? Should the experimentation in a field precede even the filing of a JSR and the assembly of an expert group?
One of the goals of JSR 306 is to "further improve the transparency of the process". Its original request has this to say on the topic:
Since the introduction of JCP 2.5 in October 2002 which regulated the right to build independent implementations, the Java community at large has grown accustomed not only to open source software methodologies and business models but on average expects that specification development happens in a similar spirit. The JSR plans to explore what steps can be taken, both mandatory through the process document, as well as voluntary or desired behavior through the Spec Lead Guide and facilities provided by the JCP.org web site.
Some JSR's are already being developed in this spirit, and some of them are doing their pre-spec experimentation and implementation work here on java.net. Two examples are the Beans Binding project (JSR 295) and the Swing Application Framework (JSR 296). Patrick Wright praises both in asking the JavaLobby audience Should JSRs be developed in the open?
In my experience, many JSRs are developed in secret, by which I mean the expert group does not allow outsiders to follow either the work in progress (code or APIs, if there are any), active discussions or records of discussions. The JCP, to my knowledge, does not require opening up the process, but seeing the high-quality feedback on JSR 296 (and how well Hans fields and incorporates it), I'm tempted to say that the default should be to require open access to mailing lists and code, even if read-only.
He also notes the downside of the traditional, closed approach:
I think one of the biggest downsides of having a closed, opaque and private process is that those of us who end up as users of the specification lose sight of the reasons why it ended up the way it did. There are reasons why generics were implemented using erasure; IMO, those reasons are something any educated user of Java generics needs to understand before entering into debate about them. Making the discussion behind those decisions public enables us to understand, or as necessary research, the reasons why we have what we have. It informs and deepens the debate.
But is this really a good idea? If you're an expert in some topic area, do you really want that many eyes on your work, that many people offering opinions (of varying levels of competence), when you need to focus on delivering a solid JSR draft? There are two sides to this story; will the kind of open process being used by JSR 295 and 296 groups work for everyone?
Also in Java Today ,
Author Elliotte Rusty Harold makes his case against another proposed JDK 7 language feature in Type Inference: Another Bad Idea for Java 7 , and goes on to say that too many changes in the Java language have made it practically un-teachable. "It's time to call a halt to new features in the Java language. I am not saying that the features are wrong, just that they don't fit into the language any more. It's already too bloated. I am not saying that generics, type inference, closures, compiler created factory methods, and other kitchen sink proposals are bad. They're not. I am saying that they simply don't fit into or with the current core language, and every one we add makes the language worse, not better."
JavaChecker is a static analyzer of Java source code, allowing you to detect code defects, such as inaccurate exception handling, style defects, violations of standard usage contracts (such as overriding
equals() without also overriding
hashCode()), and inaccurate resource usage. The project's goals are to discuss approaches detecting common java code defects and to build an open framework for applying rewriting rules to source code analysis.
In our Feature Article ,
XQuery For Java, An Enabler For SOA , Sowmya Hubert and Binildas C. A. take a look at the abilities of XQuery to simplify working with XML documents. "In this article we are going to talk about XQuery and its derivatives including the XQJ (XQuery API for Java) specification, which is under development as part of JSR-225: XQuery API for Java . The first section of this article will introduce both XQuery and XQJ and equip the reader with some code and tools to get their hands dirty. Then we will revisit the questions raised above, taking a particular context as example. We proceed by first understanding the real pain points experienced by developers in data transformations and then we take the reader through a simple case study, again with some working code."
In today's Weblogs ,