140 characters wasn't enough to write my thoughts down on Stephen Colebourne's blog post about the JCP I came across via @snoopdave. Since I live in Java land I've thought a lot about the JCP, Java, and how things will be once Oracle absorbs Sun. No one really knows what Oracle may, or may not do with Java and the JCP but one thing I'm certain of is that things are changing whether Oracle does anything about it or not.
I've been following the long saga between The Apache Software Foundation and the Sun over Apache Harmony for a while now and there are definitely problems with the JCP that need to be resolved. Colebourne's post shows the declining trend in numbers of JSRs submitted to the JCP and brings up the question as to whether this is a sign of the times for the JCP or something normal for a maturing language such as Java.
I think the answer is a bit of both. As Colebourne points out, his chart only includes new JSRs and not ones that are in maintenance mode or being updated, such as Java EE 6 for example (which connects about 30 other JSRs, most of which are not new). Since Java is a large platform that has been around for quite some time now that seems very normal to me from a mature language.
The other part I'm starting to see comes more from how other standards outside of Java come about. To me, the JCP often is done in a backwards sort of manner where the spec is defined before any real code has been written. EJB is a good example of a spec that was very complicated and had to go through several painful revisions (Ask Java devs about EJB 2), before we started to see a push to make the spec simpler (EJB3). This sort of spec first code later attitude seems to be challenged more and more by the rough code, general consensus crowd. A couple of good examples that come to mind are Spring and OSGi which both came about outside of the JCP and both now have JCP experience in different ways.
Rod Johnson of Spring also believes in rough code, general consensus when he wrote about his and Spring Source's approach to the JCP. This move towards proving technologies and techniques before submitting a JSR is something we will see happen more and more as Java progresses. JSR330 - Dependency Injection for Java, is a good example of this happening. JSR330 combines the knowledge learned from Spring and Guice to define some basic annotations for Dependency Injection in Java.
In the end, I'm glad to see fewer JSRs being submitted and giving more time for techniques and technologies to adapt and mature before working through the JCP to define a standard. Now all we need to do is get more people to experiment with closures and reified Generics...