Tags: OpenJDK
I'm drawing on several threads of thinking in several presentations and conversations this week at JavaOne, and am thinking the Java Community Process (JCP) no longer serves the needs of the Java ecosystem. I'm not the first to say this, not the last, but here's a few thoughts anyway. Sun (soon Oracle) is the owner and for the process to work out well the owner has to be enlightened enough to serve the needs of others as well as their own needs. In reaping rewards from building an ecosystem requires having the wisdom that your benefit comes from everybody happily using your ecosystem, and always acting to nurture the ecosystem you've built. Some styles of gardening (Permaculture) recognize this principle. However administrations change and while one set of people overseeing Java might be enlightened the next set might be money grubbing short sighted opportunists. I'm not pointing fingers at anybody, just outlining a general principle.
The question is.. is it appropriate to have the foundational pieces of the Java ecosystem in the hands of one company? Or is it better for those foundational pieces to be in the hands of a consortium whose purpose is the benefit of all?
Open process - When Java was first developed in the mid 90's the open source software world was nowhere as mature as it is today. In 1995 the open source software scene was very primitive even if some specific pieces of that scene were well developed and widely used. The JCP was born in that environment and historically has served mostly big business and mostly acted behind closed doors and secrecy. In todays world where the open source software scene is much more developed and accepted, is closed door secrecy of any use now? Of course the JCP has been undergoing reforms, a good thing. Also a language specification, VM specification, etc, those are not open source software, they are specifications. The IETF is an example of a standards organization developing standards out in the open in a way I longingly remember from the early 90's when I was still an electronic mail expert.
The JCP setup is tailored to the old model of iterating the Java platform. There is a platform JSR to define the Java <n+1> and a passle of specific JSR's for each feature in Java n+1 are formed to steer those features through the design and development process. This tied well with Sun's traditional 18 month or so development cycle of delivering a huge amount of change in 18-24 month cycles.
Does that model still serve us? Or is there are model with shorter cycles which would serve us better? For that matter Sun has been successfully delivering feature changes in the "6 update" train, going against their former rules of not adding features in update releases. (updates were only for bug fixes)
Having short cycles offers a lot of potential benefits. Witness what the Ubuntu, Fedora, etc projects have been able to do with short cycles. It means rapid adjustment of direction with changing conditions. It means a bug fix has a greater chance of getting into the platform than previously. etc.
Source:
weblogs.java.net
