Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies:
14 -
Pages:
1
Should JSRs be developed in the open?
At 6:45 AM on Apr 17, 2007, Patrick Wright wrote:
Fresh Jobs for Developers Post a job opportunity
- JSR 295: Beans Binding, http://jcp.org/en/jsr/detail?id=295, recently opened up a java.net project where you can download the complete current code in progress--not just the docs, but working code. The project has an open-access mailing list.
- JSR 296: Swing Application Framework, http://jcp.org/en/jsr/detail?id=296, is also on java.net, and there's already a very active community on the mailing lists discussing the code in progress--and lots of feedback from the spec lead, Hans Muller.
- JSR 294: Improved Modularity Support in the JavaTM Programming Language, http://jcp.org/en/jsr/detail?id=294, just opened up their mailing lists for read-only subscriptions.
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.
In fact, I don't see anything wrong with read-only discussions for most purposes--it's great that JSR 296 and 295 expert group members are willing to moderate and interact on the mailing list, but given that many people participate on their own (unpaid) time, it seems unfair to ask them to moderate a mailing list as well. The fact that 294 is read-only means that at least we get to see which way modularity is heading, even if we can't talk back.
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.
On the other hand--some individuals may not want to contribute if their comments will be public. Some participating companies may not want to tip their hand about internal projects or planned products and if JSR discussions were public, they might restrict their employees from participating in sensitive JSRs. Who knows--Sun may lose opportunities to sweet-talk some other company into donating code or IP rights (I don't know if this happens, but assume it does). I can't think of many other reasons why discussions shouldn't be public by default, though. I'd prefer to think of the JCP as an engineering body and not a political body (ok, stop laughing).
So what do you all think about JSR 294, 295 and 296 and their decisions to open up their processes? In my view, this can only lead to better specifications coming out the other end, and is something we should all expect from the JCP. And it seems that openness in process goes hand-in-hand with openness in licensing.
14 replies so far (
Post your own)
Great development
As someone who ends up implementing specs without being a member of expert groups writing them, the ability to look at a discussion archive (even read-only), and figure out 'what is the rationale for this' is really, really nice.Additionally, it offers insight into ideas the JSR explores, and allows the interested parties outside the expert group to aid JSR development.
Thanks to the spec leads for making it happen for those JSRs, and I hope other spec leads will follow their example.
GNU Classpath - Core Libraries
IRC: irc://irc.freenode.org/#classpath | irc://irc.freenode.org/#kaffe
Re: Should JSRs be developed in the open?
Your list should have included JSR 291, which is nearing final ballot now and was run with a public read-only mailing list. I believe it was the first one in this respect, and a lot of credit should go to Glyn Normington (the 291 spec lead) for making it happen.Re: Should JSRs be developed in the open?
Yes, they should as much as possible. There's not much in the JCP rules that stand in the way of performing the JSR openly and transparently so it is up to what the spec lead and the expert group are comfortable with.Onno.
Re: Should JSRs be developed in the open?
Another possible reason for a (semi) closed process is to prevent dilution of their concentration. A small concentrated group of very experienced individuals may want to work out details undisturbed. It's likely that random comments just creates noise. Often when people think they're contributing something, a group like this is miles ahead of you and have been-there-done-that ages ago. Having to explain their rationale takes away from their concentration.I think that if you put in enough worthy, structured, constructive, helpful, stimulating, and non-confrontational efforts, you become recognized and become part of the club.
Sounds kinda elite and special and everything, but if a small concentrated group wants to keep the intellect and concentration as high as possible, this is the way to achieve it.
Re: Should JSRs be developed in the open?
Great post. With all the uniformity and structure of the JCP, I'm surprised that the openness of the expert groups is left up to the group lead. While I'd hate to see the current "design by small group" messed up by the noise of the masses, I don't see any real downside to providing read-only access to mailing list discussions.It would be fun to watch that process.
Re: Should JSRs be developed in the open?
Is there effectively any such thing as read-only access?If the expert group has a close decision to make and the discussion related to the decision is available for all to read, there's no way to prevent the community from commenting on the decision to each other, and bombarding the members of the group with unsolicited input.
For example, imagine if Scott Violet had allowed read-only access to the JSR-295 process much earlier, say 12-18 months. To the degree that the use of EL in the binding spec is controversial, there's no way that he could've avoided receiving input from the community. The difference would be that it would've all been through various back channels: blog entries, forum messages, and direct email.
Re: Should JSRs be developed in the open?
> Your list should have included JSR 291, which isMy apologies--I was only trying to mention a few which were "opened up" in recent months; was not trying to exclude any or pick favorites. Thanks for bringing 291 to my attention, and kudos to the spec lead.
Patrick
Re: Should JSRs be developed in the open?
> Another possible reason for a (semi) closed process> is to prevent dilution of their concentration. A
> small concentrated group of very experienced
> individuals may want to work out details undisturbed.
> It's likely that random comments just creates noise.
I can understand that; I've think we've all heard the noise.
> Often when people think they're contributing
> something, a group like this is miles ahead of you
> and have been-there-done-that ages ago. Having to
> explain their rationale takes away from their
> concentration.
I agree in part, by myself would be more careful about how to state it. I have seen how individuals explain themselves, once and again, quite patiently--Neil Gafter is a great, current example in the BGGA discussion--and have also seen "discussions" where a persistent, ill-informed "participant" returns with the same questions and complaints time and again, regardless of the response they get. Certainly we shouldn't force anyone to put up with that.
On the other hand, just allowing outsiders to read the ongoing discussions--or even some summary of ongoing discussions--doesn't distract anyone, as far as I can tell.
In the end, there are two goals I have here--to be able (occasionally) to provide feedback, which is sometimes the same feedback that others have, in which case I'm glad to just support their feedback; and second, to have up front and in the open the reasons why certain decisions are being made. Let's keep in mind these are fundamentally technical decisions we're talking about here. Regardless of the obvious financial and market interests behind some specs, this is still about software. I already know the decisions (that's in the spec), I want to know the reasoning behind it as well. If I get to follow the debate as it proceeds, even better.
> I think that if you put in enough worthy, structured,
> constructive, helpful, stimulating, and
> non-confrontational efforts, you become recognized
> and become part of the club.
> Sounds kinda elite and special and everything, but if
> a small concentrated group wants to keep the
> intellect and concentration as high as possible, this
> is the way to achieve it.
It's fine with me if the groups are small and made up of experts in the field. In most cases I don't expect to have anything to add to these processes. I'm not expecting anyone to ask me for my opinion, nor am I expecting we have large town hall meetings or open mailing lists. I do think that the Swing Framework specification and recently opened project is a great example of how this can work, however. I'm on the mailing list and am following everything and to date have not needed or wanted to say a word. But my sense is the spec is benefiting from the increased exposure and early review.
Regards
Patrick
Re: Should JSRs be developed in the open?
Hi Dave> Is there effectively any such thing as read-only
> access?
>
> If the expert group has a close decision to make and
> the discussion related to the decision is available
> for all to read, there's no way to prevent the
> community from commenting on the decision to each
> other, and bombarding the members of the group with
> unsolicited input.
How does the bombarding take place? I'm sure there's a risk of people's emails getting out, or the blogs of expert group members getting spammed for their decisions. Or--what are you worried about, negativity and hate mail, or just unsolicited input?
As far as I can tell, the internet is full of unsolicited input.
>
> For example, imagine if Scott Violet had allowed
> read-only access to the JSR-295 process much earlier,
> say 12-18 months. To the degree that the use of EL
> in the binding spec is controversial, there's no way
> that he could've avoided receiving input from the
> community. The difference would be that it would've
> all been through various back channels: blog entries,
> forum messages, and direct email.
But what is the alternative? In this case, for better or worse, we've now had a first draft dropped on our laps, EL and all. There was a warning from Scott a few months ago that this was included, and now we see it's central. How is that good for anyone? I *do not* want to pick on beans binding here, so let's step back from that particular spec. If the process is not open then those core decisions are not only out of our hands but our chance for realistic feedback (which can address core issues) is out of our hands as well.
I think it's a difficult issue. I have nothing useful to say, now (or I suspect in the future), about the work on the concurrency utilities in Java 5, or, say, NIO. I just don't have the experience. I'm glad there are experts working on those problems.
On the other hand, to delegate these standard practices, libraries and specifications to "experts", who operate in secret and away from public review (sorry, been re-watching the X-Files lately), and to only get a chance to comment pretty late in the game has little to do with establishing a "standard" as far as I can tell. That seems like standard by fiat.
So--I think the feedback is necessary, whatever form it takes, but I'm willing for it to be indirect as long as the first goal (openness) is fulfilled.
Regards
Patrick
JSR-310 Dates and Times too
Just thought I'd mention that as co-spec lead for JSR-310 - Date and Time API, I always intended it to be fully open.Now its up and running it is fully open, with a java.net project, wiki, svn repository and read/write mailing list. To date there have been just a handful of private emails. Not every project can be run this way, but if they can, they should be.
Thank you, Stephen
It's great to see spec leads provide so much transparency.GNU Classpath - Core Libraries
IRC: irc://irc.freenode.org/#classpath | irc://irc.freenode.org/#kaffe
Re: JSR-310 Dates and Times too
> Just thought I'd mention that as co-spec lead for> JSR-310 - Date and Time API, I always intended it to
> be fully open.
I believe this is a great way to do a new JSR, but of course, it will not work for every JSR. It depends on the size and complexity of the spec. And maybe also the competence level needed to understand the details of it.
I follow the JSR-310 mailing list out of curiosity, which convinced me to make a small contribution. It is satisfying knowing that I make have contributed to developing Java (although one small part of a very big picture).
Georg
JDO 2.0 (JSR 243) was opened up long ago
JDO 2.0 has been open source for quite a long time now. The API & TCK, along with some other projects, are part of Apache JDO. The JDO RI is JPOX, an open source project.It's worked quite well, and I think other JSRs would benefit from opening up at least their codebases, if not their mailing lists as well.
-matthew
Re: Should JSRs be developed in the open?
I think it depends on what area the JSR is focused on. I believe JSRs like 296 are largely successful because they are mainly of interest to pragmatic programmers, so the feedback tends to be very pertinent and useful. I'm working on a JSR that involves Java meta-modeling, however, and it is attracting every academic whose private agenda appears to be redesign of the Java language, even though that's not our charter. The expert group is committed to an open development process, but the signal-to-noise level is so low on any given day half of us feel like quitting.