Skip to main content

Is the JCP fundamentally the wrong model (now) for Java?

Posted by robogeek on June 4, 2009 at 9:29 AM PDT

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.

Related Topics >>


The JCP should be dissolved - because of 11 years of abusing the word "community" and doing a disservice to the community. Reforms? I just see lip service. Some symptoms are now singled out, the root cause is still ignored. The JCP has its head deep in "where the sun doesn't shine" of big corporations. And the JCP feels very comfortable in that position. That's where they smell money, fine closed-door work without the need to face the real world.

I think "the" JCP model definitely needs tweaking, but frankly, it has been evolving all the time--as shown by the recent, and largely successful, push for greater transparency, the move to do something about inactive JSRs, etc. At this point, there are definitely issues with Java 7 and the role of Sun as a player with special rules. To Sun's credit, the JCP is a pretty good deal in the world of commercial software. Sure, we have the Apache, Eclipse, and Mozilla foundations, and I want the JCP to move closer to those, but look elsewhere. Microsoft and Oracle have nothing like the JCP. Having talked with some of the JCP principals, I think they should be given a chance to continue their agenda for change in these uncertain circumstances. I think the best thing we can do now, with you-know-who about to step in, is to support the JCP as a basically sound model that needs evolving to even greater openness.

I obviously need to update my bio as I haven't been employed by Sun for over 5 months now. As for incompatible technologies, what do you think about Android?

This is an interesting debate, but perhaps your position as a Sun J2SE engineer is not ideal - people may cry bias, as as Sun is (so far) blatantly ignoring the JCP by nor starting the Java SE 7 JSR. Not to mention JavaFX; I understand that proprietary development is much more agile and was necessary for the first releases, even the secrecy may have been necessary due to commercial aspects especially wrt Mobile deals and Java Store. But that was then, and this is now: JavaFX 1.2 is already mature enough that I'd expect at least a strong official committment (with a target date) to either full open sourcing, or JCP standardization, or both. But this JavaOne will end with JavaFX remaining a proprietary, non-open project, even though Sun has clearly promised at least the full opensourcing in the past. This is a big disappointment for JavaFX enthusiasts like me, and a risk if Sun wants bigger developer adoption (the whole Linux crowd may ignore JavaFX just because it's another "Java Trap"). Having said all that... yes, perhaps we need at least a big refactoring of the JCP. But I consider important to have formal standards of some kind, and even more important, formal TCKs. I don't want to live in the chaotic world of grassroots FOSS projects that compete and evolve (sometimes) with zero care for compatibility and interoperability; I don't want to see Java versions of disasters like Linux's KDE versus GNOME, or dozens of incompatible and incomplete sound stacks. (OK, we already have some similar disasters like EJB/CMP vs JDO vs Hibernate, but they eventually converge to a better standard, like JPA.)

I somewhat agree with CayHorstmann's viewpoint, and having formerly worked at Sun I do know many of the JCP principals as well. One thing about reforming an organization is to pull the organization into the direction you want it to go. For the JCP to rapidly move into a more open way means yanking on it's arms and otherwise pushing it into freedom and openness. I think if we simply sit patiently waiting for change, the change may not occur or may not occur rapidly enough to be useful. And, uh, abusing the word "community".. yeah, amen bro.