Java Community Process

James Strachan continues the JCP discussion, regarding his experience with JCACHE.

I totally agree with Cameron on this. JSRs should be developed in the open. Anyone should be able to comment on JSRs, while they are still under development and see the discussions that their comments cause. Right now any comments you send to a JSR from your perspective typically just go into a black hole.

I'm on quite a few JSRs, including the JCache JSR (and developed the first non-Oracle JCache implementation at my employer, SpiritSoft). I think its very sad that JSRs don't operate in the public.

Sun's reasoning behind this is that typically various companies on the expert group need to give away details of their intellectual property and so only want to do this in private amonst other people who have also signed NDAs. This NDA issue is a real problem in big business, but then maybe this highlights that standards should mostly be created by individuals, in a totally open manner (like most open source projects) rather than being vehicles for big business to gain competitive advantage.

I've often wondered if a new standards body could form, following the Apache style guidelines to running open source projects, where standards are created in an open manner using a meritocracy.

My only two direct experiences with the JCP were...

  1. The JDOM JSR (102, I think). Pretty much developed around the refence implementation (JDOM) and in the open on the jdom-interest list. But, I'm annoyed that it isn't very clear to most people that JCP is merely a process and not necessarilyi some form of blessing form Sun. And as far as processes go, I think the JCP is a pretty bad one for all the reasons Strachan and others have outlined. With JDOM having a JSR, I've seen many folks assume that JDOM will become the officilal or sanctioned object model for XML. This is not the case, and if you read through the jdom-interest archives, you'll hear the founding members say as much.

    I was, for a while, a member of the JDOM expert group due to my contributions through the Jaxen XPath engine. Aside from adding some comments via jdom-interest, which anyone could do, I didn't really feel that special. The JDOM JSR is also probably one of the slowest moving on the JSR track.


  2. As implementor of drools, I have an interest is JSR-94, the Java Rule Engine API. I had many many folks ask if drools would support JSR-94 even before it was publically available. It's a question that everyone asks and that no implementor can answer until actually able to judge the appropriateness of the JSR.

    I deemed JSR-94 to be inappropriate in its public-review form to give any effort towards making drools compliant.

    As requested during the public-review period, I compiled my comments and sent them to the comments address. I've heard absolutely nothing in response. I have no idea (and absolutely no faith) that JSR-94 will in any way be affected by my comments.


With a few exceptions, the JCP is most definitely a Cathedral and not a Bazaar. It's a cathedral behind a very tall, very thick hedge. Surrounded by a moat. With alligators and snakes.

About this Entry

This page contains a single entry by bob published on October 14, 2002 9:39 AM.

Planning and Scheduling was the previous entry in this blog.

Internal APIs is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.