Search |
||
A Call to Fix the JCP Oberver StatusPosted by cayhorstmann on January 22, 2009 at 1:20 PM PST
As a book author and glutton for punishment, I am often interested in bleeding-edge Java technologies, as they are cooked up through the Java community process. For example, when David Geary and myself wrote the first edition of our Core JavaServer Faces book, we needed to work with the early access versions of the spec and reference implementation (RI). At the time, source for the RI was only available to members of the expert group, and I had to use a decompiler to get an approximation of the source from the binary files. It was surprisingly effective, but not something that I care to repeat. Fortunately, now the RI is developed with a public version control system on java.net, so that problem has gone away. But the spec is still very hard to read, and it would often help to have some background information on the thinking behind it. Unlike a true open source project, the expert group discussions are not public. The spec is only publicly updated at infrequent intervals and is often at variance with the RI.
When I complained bitterly to my fellow Java champions, someone suggested that I join any JSRs in which I am interested as an observer. This and this and this article tout the benefits of the observer status. It turns out that, in order to be an observer, you first have to become a JCP member. That requires that your employer signs off on some pretty heavy legal paperwork. The JCP is naturally concerned that an employer doesn't later claim that some idea that made it into some JSR work product is their property. I didn't think there was any hope that anyone at my employer (San Jose State University) would understand the paperwork, or have the courage to sign it. But fortunately, I don't work for them during for the entire year, so I just signed it as a self-employed person while I was on break. I then dutifully followed the process to sign on as an observer to a couple of JSRs (including JSR 314 for JSF 2.0), and the result was . . . nothing. I emailed Ed Burns, the spec lead, and he responded: CH> Hi Ed, CH> I am an observer for JSR 314, but I am confused as to how I can observe. CH> I naively assumed I would get some way of monitoring how the spec CH> evolves, perhaps through read-only access of a mailing lists forum, and CH> by being able to see proposal drafts. I logged onto the JCP page, and it CH> has no contents. I was added to the observer alias, but have not CH> received any email. Do I need to activate this in some way? The observer list is very low traffic. We use it for announcements on the availability of new drafts. We don't have a publically observable list for JSF 2.0. We charged Kito with maintaining a public JSF 2.0 group blog, but he hasn't updated it. It's at <http://blogs.jsfcentral.com/jsf2group/>. Please prod him to update it.
Well, I am sorry, but that stinks. That's not openness. I think the JCP needs to move up to the next level of glasnost. I have sympathy for the poor spec leads who aren't given a lot of guidance. So the JCP should provide some guidance, such as:
To their credit, JSR 314 has a publicly accessible issue tracker. I don't think there is any evil intent to hide the discussions and drafts. They just didn't start out with a mechanism that made it easy. That's why I think the JCP should put every new JSR on notice to make all information public by default. What's in it for you, the user of Java technology? Better technology, I think. Expert groups can have unhealthy dynamics, such as group think, design by committee, and a mad rush to adopt half-baked ideas just before deadlines. JSF in particular has some unhappy features, and absences of features. When the process is more open, interested people can watch what is about to happen, blog about the good and the bad, and raise awareness in the wider community. If you agree, please kvetch in the blog comments so that the JCP folks pay attention. Update March 4, 2009: JSR 314 has just decided to make their email discussions and spec drafts public! Thanks to Ed Burns for doing the right thing! »
Comments
Comments are listed in date ascending order (oldest first)
Submitted by mojavelinux on Sat, 2009-01-31 13:50.
Amen! Openness is the key. I think that specs should be hashed out on public mailing lists. JSR-299 follows this approach and is enjoying great success and buy-in because of it.
Submitted by pelegri on Thu, 2009-01-22 22:44.
I like the way JAX-RS works. See https://jsr311.dev.java.net/ - eduard/o
Submitted by cowwoc on Fri, 2009-01-23 07:34.
I agree with the author. All discussions should be public. I too like the way JAX-RS works, though I hate the java.net mailing list that they use. I would advocate the use of Nabble so we can use the forum or mailing list interface depending on our preference.
Submitted by pelegri on Fri, 2009-01-23 07:54.
re: Nabble - yep, many of us use alternative ways to navigate/interact with the Java.Net aliases. Some of them are read-only, like MarkMail (see [1]), some allow postings, like Nabble, in some cases, like with the main GlassFish aliases, they are kept synchronized with Java.Net forums, like with [2].
[1]http://markmail.org/search/?q=list%3Anet.java.dev.jsr311.users
[2]http://forums.java.net/jive/forum.jspa?forumID=56&start=0
Submitted by robc on Fri, 2009-01-23 12:56.
Switching JSRs to a more transparent way of operation in mid-flight is logistically challenging, but I believe that every future Java EE-related JSR should adopt the JAX-RS model.
Submitted by pcurran on Fri, 2009-01-23 16:40.
You're quite right, Cay - we need to fix this. And guess what? We're actively working on it.
We had a long discussion about exactly this topic during the December Executive Committee (EC) meeting. Not only do we believe that Expert Groups should operate transparently, but so should the EC. So: we recently changed our policy, and decided to make all meeting minutes and presentations public by default. The full minutes for the December meeting have not yet been published (since the EC hasn't yet approved them). When they are, you'll be able to find them at http://jcp.org/en/resources/EC_summaries.
In the meantime, here's a link to the presentation that we discussed in December: http://jcp.org/aboutJava/communityprocess/ec-public/materials/2008-12-09....
You might also want to check out the archive of a webcast on the subject of transparency that we broadcast to Spec Leads back in September. See http://jcp.org/en/resources/multimedia.
Patrick Curran
JCP Chair
Submitted by pcurran on Fri, 2009-01-23 16:53.
One other comment:
As for your concerns about the "heavy legal paperwork", the simplest solution to this is probably to join via your local Java User's Group, so long as it is a member, or is affiiliated with the JUG-USA (an umbrella organization that is in the process of joining the JCP - see http://weblogs.java.net/blog/van_riper/archive/2009/01/jugusa_the_whol.html).
Submitted by cayhorstmann on Fri, 2009-01-23 17:17.
Thanks for the update, Patrick! I am glad this is being addressed, and I hope it trickles down to the spec leads ASAP. I love the "How they see us" image in the PDF :-)
Submitted by mwessendorf on Sat, 2009-01-24 07:22.
+1 Cay!
I am totally with you and I also don't like the way that expert groups go. The JCP stands for java COMMUNITY process, but what I see there is (in a lot of the EGs) no community allowed (or welcome). I see that some vendors are scared by the wider public when they put in their IP, but that is mostly the case in the J2ME world.
Back to the JSF EG... Apache is a member of that spec and as a member it is possible to have a read-only access-mailing-list (to be used inside of a company/organization). So, an idea was to create such a list for committers that are a) interested and b) sign the NDA. Because this EG isn't handled via the good principles of open_source communites, we decided against creating such a list. I would really like to see more and more real open EGs with RIs and TCKs under a liberal license, which is IMO Apache 2.0 (and/or BSD).
Submitted by mwessendorf on Sat, 2009-01-24 07:23.
Patrick, thank for addressing that issue. Have to read your references now. Thanks!
Submitted by javawerks on Sat, 2009-01-24 14:45.
Cay, all the best with your new book and opening the JCP. The JCP has become increasingly irrelevant, though. Its failures have been spectacular and many. Most of us have simply moved on to open source Java technologies. Perhaps, you may want to consider doing the same with your next book.;)
Submitted by ewin on Sun, 2009-01-25 09:13.
I am not sure if the JCP (btw, in practice the C stands for corporate, but certainly not for community) is irrelevant. But no doubt it should become irrelevant. If they think they can fix things with a bunch of PowerPoint slides, teleconferences every three month, and doing buzzword bingo like "agile", "transparency", "leverages the diversity of communications means", and looking for "marketing representatives" they are badly mistaken.
Any effort by the community (the real one) to make it irrelevant is well spend. The community should help them to stick their PowerPoints and the JSPA where the [Ss]un doesn't shine.
Submitted by pelegri on Sun, 2009-01-25 10:23.
javawerks & ewin - I tried to capture my point at [1] but will be happy to continue the exchange in this thread. - eduard/o
[1]http://blogs.sun.com/theaquarium/entry/jcp_open_source_reduced_tco
Submitted by dfoster on Tue, 2009-01-27 17:06.
This my official kvetch in support of the ideas and remedy presented in this post.
Submitted by edburns on Wed, 2009-03-04 23:08.
Cay, I've posted a response to this on my blog at http://weblogs.java.net/blog/edburns/archive/2009/03/response_to_a_c.html.
Ed
Submitted by heathervc on Fri, 2009-03-20 15:37.
See the post on the JCP program office blog regarding JCP 2.6 Maintenance Review and Observer Aliases:
http://blogs.sun.com/jcp/entry/jcp_version_2_6_ready
Also see the post on Transparency Survey:
http://blogs.sun.com/heathervc/entry/how_transparent_are_you
|
||
|
|