Debate: What role will the JCP play in Java's future?

Posted by Ryan Slobojan on Dec 11, 2007

Sections

Process & Practices,

Development,

Enterprise Architecture

Topics

Community ,

JCP Standards ,

Governance ,

Java

Tags

JCP ,

OSGi ,

JSR 277

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:

1. Sun ignores the JCP legal agreements it signs (ie. wrt Apache Harmony). This destroys all trust.
2. 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.
3. 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.
4. The JCP is not eliminating duplicate JSRs (see OSGi). Worse, it is allowing the worse option to succeed.
5. 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?

1. Back to top

   OK

   by Michael Neale

   I don't think its a bad thing. JCP made sense when java was proprietary. Now there is OpenJDK - a whole new set of dynamics has to come into play.
   
   On the language front I would like to see lots of innovation (some first class support for languages other then java), Consumer JRE seems to have legs. Java 6 has Rhino in it ! Isn't Javascript meant to be the Next Big Language???

   Reply

2. Back to top

   who needs JCP? let adoption define the standard

   by Nati Shalom

   I think in the world of OpenSource and open community the role of standard should be changed quite drastically.
   Anyone who think that they have good idea can just spawn their own project and do pretty much what ever they like with it.
   The checks and balances will be the adoption i.e. if your doing the right things and solving real problems then most likely you'll see that reflected in higher adoption.

   Reply

3. Back to top

   Let the market decide ... except for a module standard

   by Peter Kriens

   I strongly believe that the market should decide. However, for markets to work well you need liquidity. In our world, liquidity is seriously hampered due the many (half finished) plugin frameworks. It is hard to use someone else's modules if that module uses a different module system. Such friction in the market creates unnecessary complexity, monopolies and oligopolies which will all work against a free markets.
   
   A small VM a la Harmony with a widely supported module system will create a market of components that can then compete freely. Let the best win. This has been the model in my head for almost ten years, and I still believe that that is the way to go today.Software is already hard enough, we should not be hindered by unnecessary complexities. I get tears in my eyes when I look at CPAN (Perl repository) and think we could have a better repository if we got our act together as an industry.
   
   One of the reasons Sun is not adopting OSGi is because they realize how frictionless the market would become when there was a widely adopted module system for Java? Or is that too Machiavellian?
   
   I know I am suspect ... but don't you think that standardizing on OSGi, as the most complete, mature and thoroughly specified module system for Java, would help create a component market so that we can compete without the shepherd grazing with the sheep?
   
   Kind regards,
   
   Peter Kriens

   Reply

4. Back to top

   Re: Let the market decide ... except for a module standard

   by Nati Shalom

   See my response on Who needs standard anyway

   Reply

• Older >