I've written several books on Java, and during the course of some of them I've had to spend a lot of time reading the standards documents that emerge from the Java Community Process (JCP). I am not a fan of the JCP.

This is not because I have a problem with the documents themselves; they are of variable quality, but I expect that arises mostly from the membership of the expert groups who create the standards. Since I have no particular desire to be on them I can't complain too much. Writing standards is hard and I couldn't do it half as well.

No, the problem I have with it is how closed the whole thing is if you aren't on the expert group. They produce a lot of documents, but they are handed down as from the gods. They appear for a feedback period, so you get to comment if you think someone's made a completely awful cockup in the design, but what you don't get is any kind of window onto the standard development process itself.

Why is this a problem?

Because while the standards always try to address the hows, they don't always address the whys. The precise reasoning behind some boneheaded decision in the specification is hidden away in a mailing list that the mortals aren't privy to. And even if it's not boneheaded and there is a very good reason for it, there aren't necessarily any clues as to what those reasons might be!

Compare this with the Open Source model where most of the design decisions are usually taken by developers on mailing lists who rarely hold back from calling someone a dumbass. Ok, the JCP could use a bit more restraint, but we the victims of these arbitrary decisions would really benefit from a chance to review, understand and occasionally condemn the reasoning of its participants.

I've just written an email to the JCP Project Management Office to enquire why the mailing list is not available to external readers. I'll post an update if I get a reply.

Update 1. I have had a reply, and a fairly helpful one. I'm waiting for permission to quote from it - if I don't get that I'll paraphrase the gist of it.

Update 2. Right, here's the response I got from the Project Management Office. I'm used to getting bureaucratic answers from Big Faceless Organisations. This was refreshingly human:

We understand your frustration. The JCP Program Office is working hard to improve the transparency of the process. There are a couple of tools that are already available to our members. Every JSR Spec Lead is encouraged to set up an observer alias and a community update page.

It is possible to subscribe to the observer alias for any given JSR from the JSR detail page.
For example, the community update page for JSR 316 is http://jcp.org/en/egc/view?id=316
You can navigate to it from the jcp.org home page.
Type the # of the JSR in the "go to JSR" box in the left navigation bar and hit enter.
You will be taken to the public JSR detail page.
Below the Expert Group table, the third link takes you to the community update page.

Log in using the user-id and the password you were given when you joined the JCP.

From the community update page, under the "Community page communication" header, you will find the instruction on how to join the JSR 316 Observer alias.

The Program Office recommends to the Spec Leads to set up and use such tools. Should you find that no such alias exists, or that it does exists but has very little traffic, please feel free to contact the spec lead directly and request that the alias be activated and used.

We are also working on including new features on future releases of the jcp.org website aimed to improve transparency and community communication.

My original gripe was raised by a query I had about an existing standard - but I accept that the rules can't be changed retroactively. This response does encourage me to believe that the JCP is encouraging more openness in its process. It's not perfect - I'd like to see a publically readable mailing list be a mandatory part of the process, but at least things aren't quite as bad as my perception of them.

My remaining gripe is that the JCP home page is somewhat opaque to anyone who doesn't really understand the existing process. You can find the published standards documents fairly easily, but the details of the JCP itself are somewhat obfuscated. I had absolutely no idea that the observer status existed - because I'm not a JCP member - but if you don't want to be anything but an observer you wouldn't join unless you knew that was a benefit. Especially since paperwork has to change hands either physically or via fax (this in the age of email - I don't own a "real" telephone, surely that's not unusual for the connected generation?).

Any further updates to this issue will appear as separate blog articles.