Recently, Alex Blewitt described the Java Community Process (JCP) as dead, likening it to a headless chicken which "doesn't realise it yet and it's still running around, but it's already dead". This touched off a debate over the usefulness of the JCP and how much it will play a role in Java's future.
In his blog post, Alex Blewitt identified several concerns about Java and the JCP:
- The JCP has resulted in a larger JVM size, with very little being removed and a lot being added in
- Right now the VM requires that everything be present, nothing can be removed - the Consumer JRE is a start, but it just defers jar downloads until later rather than having them up-front - the entire JRE is still downloaded
- Java needs a new module system which allows dynamic, on-demand component downloading so that things which are never used are not downloaded
- Although module systems exist and function on top of Java today, something new is being created for Java 7 which will probably be more bloated and less functional than existing solutions, and will likely be replaced by most implementors (similar to java.util.logging and the XMl parser)
- There is little stewardship of Java's evolution (subtraction as well as addition)
- Microsoft is beating Java on the language front - .Net has several languages that are used daily by lots of developers, Java really only has the Java language with the rest being "small fry" - Java is also playing catch-up with language features such as Generics, continuations and functions as values
- Although there are some niche opportunities for cross-VM languages like Scala, the more likely future path is Google's GWT and Android approach - reuse the Java language, but target a subset of the Java APIs, and develop the product outside of the JCP to avoid the extra baggage which would otherwise be incurred
- J2ME is a disaster - there is massive fragmentation among devices, and J2ME isn't able to handle useful things like Bluetooth, USB, or dialling
- JSRs are deadweight, and just add bloat to an already bloated platform - the JCP prevents a lightweight, modular approach and true innovation happens outside of it
Blewitt also stated:
JCP is not about community; it's about Control. Read through any of the JSRs and there's a section on "Why isn't this addressed by existing systems". Reading through them is an exercise in marketing; there's invariably no real reasons there, but rather 'We can do it better/different/smaller/faster'. What really happens in these situations is that the spec leads have zero interest in building upon what's already there; they want to get in their own version of a codebase (whether real or proposed) and the arguments are essentially 'Because we didn't write it'. The so-called 'expert groups' are nothing more than a peer review process of the developers (normally the submitters of the JSR), and have zero impact on the code that actually gets developed. (Normally, the submitters of the JSR will supply the sole developers of the code rather than enlisting the help of the expert group, so that they can own all the IP of the process.) In other words, it's the sanctioned blessing of doing whatever you want to do
Others commented that Google should lead Java development, or that Java would soon be replaced by a true parallel language. However, some worried that modularity invited fragmentation of the platform.
On the same day as the above post, Jean-Marie Dautelle, co-lead of JSR 275 (Measures and Units), solicited feedback and questions from the community for the JCP:
- Alexander Hristov requested public debate, open mailing lists and open meeting
- Robert Cooper pointed out that the C in JCP stood for community, and that committee and corporate interests seemed more important than community interests
- Terrence Barr asked for more involvement from individuals and small companies, more open-source compatibility (such as less NDAs and proprietary components), and a more open approach to JSR expert group membership and acceptance of public opinions
- Brendon McLean thought that JSR 296 (run by Hans Muller) was an excellent example of a JSR done right, and recommended that JSRs always contain a domain expert, that open source solutions always garner serious consideration, and that all JSRs follow 296's lead for openness and community involvement
- Patrick Wright added input from individuals and small groups alongside corporate input, and a recognition of de-facto standards such as Spring and Apache Commons by the JCP
Dautelle's question also drew a long response from Stephen Colebourne, JSR 310 (Date and Time API) co-lead. Colebourne asked:
This question leads into broader questions of governance in Java. Java is now opens source, yet we still have no real clarification on how that works or affects the JCP.
In particular, who is the 'architect' overseeing the development of Java, and its future direction? Is it a named person in Sun? A hidden magical process? Or hit and hope?
Colebourne wondered who decides what language changes go into Java 7, how core library changes occur, and why the JSR 277 module management system is being handled like it is - he also raised several issues:
- Sun ignores the JCP legal agreements it signs (ie. wrt Apache Harmony). This destroys all trust.
- The JCP still exists to rubber stamp proposals from its big company members. Basically, a company submits code they already have, and the 'Expert Group' really exists to peer review it.
- Neither the JCP or Sun are giving any sense of direction to Java. There should be a clear sense of where Java is headed and what it is trying to be - a five to ten year vision.
- The JCP is not eliminating duplicate JSRs (see OSGi). Worse, it is allowing the worse option to succeed.
- Individuals have too small a say. They tend to provide the innovation and disruption that keeps the big companies honest.
Colebourne also proposed several solutions such as an architecture group which would publish a five to ten year vision for Java, a larger and more autonomous JCP Executive Committee, payment for JSR members, and a proper TCK for Apache Harmony. Another option which is presented is the elimination of the JCP, and the redefinition of Java as an OSGi-based modular VM built on top of a kernel - vendors could then mix-and-match as they pleased, and the market would decide on a winner. Patrick Wright disagreed with several points, pointing out that in the Apache-Sun Harmony debate only Apache has publicized their side of the story. Wright also questioned how valuable a five to ten year vision was given the rapid pace of language development.
Peter Kriens also weighed in on the debate, agreeing with Colebourne about the analysis but disagreeing with the solutions. Kriens also raised a new question - what is more relevant, an implementation or a specification? Kriens points out that a specification allows multiple implementations that target different requirements, it allows neutrality by balancing the needs of multiple organizations, the slow standardization process allows for real time to think about solutions, and problems with intellectual property rights tend to be easier to handle. Dalibor Topic responded that both JCP and OSGi are too controlled by large companies, and that specifications are encumbered by proprietary components - however, they are both worth having. Kriens responded that large company backing was important for a specification to succeed, and tha tall members of OSGi are treated equally, whereas Sun has a disproportionate amount of control over the JCP.
What are your thoughts?
