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,
ElieÂ Levy looks at the idea of the
Multithreaded Hash Table.
"If your application needs a "Hash Table" type of structure you have several options. This blog present some of them, and discusses the pros and cons of each."
Are JSPs dead? ZararÂ Siddiqi's wondering about their viability: "Seriously, anybody still use them?"
Finally, Qusay H.Â Mahmoud has some guidance for
Networking MIDlets and blocking operations.
"Pay special attention to blocking operations (e.g. methods that establish a connection to the network) which can lock up the mobile device' screen, leaving the user frustrated with the application. To prevent this, all blocking operations should be performed in a separate thread."
In today's Forums,
firefight wants to
Write to stdin.
"How can I write to stdin? I execute a 3rd party library and it prompts for password on the console. There's not going to be anyone around to type in the password so I need to do it from code. What's the standard way of doing this? Do I have to spawn a new process and use a pipe?"
arckjmasteris trying to do HTTP file upload in GlassFish, writing in
pls help, file upload to a local directory:
"Here is the problem that I am having, I don't know why it keeps on saying "access is denied" when I can see that the file is uploaded to the directory. I am developing a JSP page file upload using Jakarta Fileupload v1.2. However, every time when I try to upload a file to a local path (e:\temp) on the server I keep getting this problem. I even try looking into the server.policy file on glassfish but no luck, your help is appreciated thanks"
Why factories and parameter blocks?, asks
"I was just wondering if anyone knows why the JAI uses factories and parameter blocks rather than just straight forward classes. It would seem this choice destroys any compile-time type checking as well as many optimizations that could have been accomplished by JIT. I'm running a tight loop that requires real-time image analysis and processing on 30 fps video. My thoughts have been to move my required analysis and processing out of the JAI and into my own 2-dimensional bitmap arrays. Am I missing something?"
Current and upcoming Java
- AprilÂ 16-20 - J2EE Training Philippines
- AprilÂ 20-22 - Greater Oregon Software Symposium 2007
- AprilÂ 20-22 - Greater Quebec Software Symposium 2007
- AprilÂ 20-22 - Open Source Live! 3-Day Hands-on Seminar in Sacramento, CA
- AprilÂ 27-29 - Northern Virginia Software Symposium 2007
- AprilÂ 27-29 - Open Source Live! 3-Day Hands-on Seminar in Bellevue, WA
- MayÂ 4-6 - Rocky Mountain Software Symposium 2007
- May 8-11 - JavaOne 2007
- MayÂ 18-20 - South Florida Software Symposium 2007
- JuneÂ 1-3 - Greater Oklahoma Software Symposium 2007
- June 24-28 - Jazoon'07
Registered users can submit event listings for the
href="http://www.java.net/events">java.net Events Page using our
href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
Archives and Subscriptions: This blog is delivered weekdays as
Today RSS feed. Also, once this page is no longer featured as the
front page of java.net it will be
archived along with other past issues in the href="http://today.java.net/today/archive/">java.net Archive.
Is "open from the start" the right way to develop a JSR?