Tuesday, March 22, 2011

Subverting the JCP - Why?

Just read this post by Java lead Mark Reinhold in which he says that

It's therefore time to define a simple process for collecting, sorting,
reviewing, and prioritizing proposals and plans for new features, for
JDK 8 and for later releases.

Some essential requirements (not in priority order):

- As lightweight as possible.

- Simple mechanics.

- Version-controlled, so that changes can be tracked.

- Open to all committers, with transparent decision-making.

- The basic format should not be too different from (a simplified
form of) the old Sun "one-pager" template [1], with which many
are already familiar.

- An approved proposal should be able to serve as the authoritative
source of the summary and reference information needed for related
documents such as the release feature list [2] and the Platform
Umbrella JSR specification [3].

[emphasis mine]

A big problem I've seen with the JCP is this desire to use it as a rubber-stamp for JavaSE rather than, as most other JSRs including the JEE ones are, an actual debate on what needs to be done. I agree with soliciting feedback from a wide community and making that open (I'd argue that the JCP should be open ala OASIS) but I really don't get why we need a proposal mechanism outside of the JCP to manage this unless the ambition is to purely manage it from an Oracle/OpenJDK perspective rather than as an actual part of the Java Community Process. The proposed approach smacks of the pre-JCP days where Sun solicited feedback and controlled the process and which the JCP was set up to change.

I'm depressed, I'd like to see the JCP successful and the voices listened to not a new process created outside of a standards group and controlled by the leader of the JSR who will then present it to the JSR team as a fait accompli which is exactly what led to the debacle with JAX-WS and the problems that it delivered.

1 comment:

Eric Newcomer said...

One reason is OSGi already exists as a proven, successful module system for Java, and prior attempts were made unsuccessfully to replace OSGi through a more open process. So naturally Sun/Oracle have to resort to forcing the issue in order to attain what they apparently believe is a competitive advantage against IBM, seen as the big backer of OSGi (and Eclipse of course, as the best known application of OSGi).

Technical politics as usual! And though the vendors think they have something to gain, users as usual have a lot to lose.