The JCP is the body that looks after standards in Java, and a JSR is the individual request to create a standard. But how has the volume of JSRs changed over time?
JSRs over time
In tackling this question, I decided to focus on the simple statistic of how many JSRs were submitted per quarter over time. This does not address JSRs that were never finished, or how long the JSR took to complete, or whether it is still active and in maintenance mode.
The data as to when a JSR was submitted is publicly recorded on the JSR page, for example JSR-311 was submitted for voting on 13th February 2007.
So, without any further ado, here is the main graph of JSRs submitted over time. The red line is the total of all JSRs (Java SE, EE and ME) while the green line is only SE and EE:
Hopefully, the trend is clear - the number of JSRs submitted has been falling over time. To be clear - only 5 JSRs were submitted in the whole of 2008, and only 4 have been submitted so far this year (roughly 1 JSR per quarter).
The question is whether this is a worrying trend, or just normal for a maturing language. I suspect its a combination of factors.
In part, Java is now a platform where most innovation occurs outside the JCP. This is a good thing, and shows a healthy ecosystem that doesn't need the 'blessing' of an official standard to make a technology or product useful. Examples of this are Spring and OSGi - both were widely used without a JSR (although ironically both now have some connection to the JCP).
Another factor is that a lot of the Java EE work, and possibly others, appears to be going on as maintenance revisions to an existing JSR. This doesn't show up on this graph, as the no new JSR is created. This is fine, although it may suggest an unwillingness to go through the process of starting a new JSR.
One more point worth noting is the timeline. JavaOne 2006 was when the Open Sourcing of Java was announced, and Sun developers were taken off active development to begin the very long process of legally reviewing the entire Java codebase. This was then followed by the (mis)adventure of JavaFX, which drew even more developers away from core Java and new developments. There may be some signs of this in the graph, where the steady state of 2004-2006 declines at the end of 2006.
Finally of course, there is no doubt about the absence of Java SE JSRs for Java SE 7 (language changes and API changes). I've written before about the politics behind this.
Certainly I see the JCP as being at a crossroads. The Oracle acquisition is key here. Oracle could choose to reinvigorate the JCP, with industry partners, ideally separating the JCP from Oracle itself, as IBM did with Eclipse. However, given the money Oracle is spending, I suspect that won't happen, despite their previous sentiments.
Unfortunately, continuing the status quo doesn't wash either. At present, the JCP is deadlocked on how to proceed with the Java SE 7 specification. As a result, JDK 7, Project Jigsaw and Project Coin are proceeding outside the JCP. Plus of course, JavaFX isn't related to the JCP at all.
Summary
The JCP has considerably fewer JSRs being submitted now than the 2000 to 2003 period. This doesn't quite mean that the JCP is dead or no longer has value, but its another data point as to how Java is maturing and stabilising. Or perhaps less kindly - fossilising.
Feedback welcome.
Another explanation is that the Java community has become more organized and is submitted fewer JSRs as a result of better pre-submission collaboration.
ReplyDeleteIt'd be interesting to see the number of JSRs accepted/finished over time OR the number of person hours per quarter devoted to JSRs (divided out by Sun employees vs. community employees). Those numbers don't exist but might be a more accurate reflection of what's happening in the community.
Fossilizing is a good description of the current affairs, imo. The interview on JavaPosse regarding Project Coin made it crystal clear that Sun is not willing to make a large enough investment in the language to figure out how to push through large changes without massive disruption.
ReplyDeleteIf they can't do that, fossilization is the ultimate endgame for Java the language in the mid-to-near term.
This is a great graph and it cannot be explained by "better organization" among participants, sorry.
ReplyDeleteThe JCP was formed by the major vendors (Sun, IBM, Oracle) as a counter-balance to Microsoft. That threat is now eclipsed by the threat from open source. Each time you create a standard, it can be commoditized by an open source implementation, so why bother?
JBoss found a neat hack for making money (commoditizing industry standards) which ended up undermining the very ecosystem that spawned it by reducing participants incentive to play the standards game. This was inevitable and JBoss just did it better than anyone else.
Spring's success and Sun's decline proved the irrelevance of the JCP even more than the major vendors' disregard.
Can Oracle reinvigorate the JCP? Yes, but only insofar as they view MS as the threat and open source as the answer to that threat. In those cases, they are happy to write the standard and let Red Hat, Google or VMWare(!) implement it.
As for their true strategy, Oracle ultimately wants to make money and so they will continue to move further up the stack, using standards only when necessary. So I don't think this will really count as reinvigoration of the JCP, just life support ;-)