Ensuring Speed and Openness at the Java Community Process: A Conversation With Onno Kluyt

Print-friendly Version

Articles Index

Onno Kluyt, senior director and chair of the Java Community Process (JCP) and a native of the Netherlands, has been hard at work facilitating a smoother, faster, and more open process. We caught up with him recently to get his take on how things are going.

What are the greatest misconceptions about the JCP?

There are two: First, that Sun controls everything, and second, that standardization is slow.

Let's start with the latter and address that by making a comparison. From February 2000, when Java 2 Platform, Enterprise Edition (J2EE) first came under JCP oversight, until today, the JCP has delivered three versions of J2EE (1.2, 1.3, and 1.4). And by the first half of 2006, we will have delivered the fourth version, Java EE (Java Platform, Enterprise Edition, formerly known as J2EE) 5.

"In the first three years of the JCP's existence, JSRs took 100 to 150 days longer to complete than JSRs that were started in the last three years."     Onno Kluyt Senior Director and Chair of the Java Community Process (JCP)

In that same period, Microsoft still has to get around to delivering Longhorn. I don't call that slow -- I call that a very competitive pace. The same argument can be made for the Java SE (Java Platform, Standard Edition, formerly known as J2SE) platform. With a current running total of 28 JSRs (Java Specification Requests), there are going to be a few standardization efforts that take their time -- the proverbial black sheep in the family. But the majority of the JSRs complete on pretty good schedules.

And the process has sped up. In the first three years of the JCP's existence, JSRs took 100 to 150 days longer to complete than JSRs that were started in the last three years. This statistic shows that the changes we've made over the years are paying off and that the community has grown more skillful in creating and delivering this technology together.

Among these changes are initiatives like the Star Spec Leads Program that was introduced to support JSR spec leads and the folks that bear the brunt of the standards-development work. It's important to communicate their successes to the broader community, who can then emulate their work approaches.

So what about Sun's control? Sun has more control than other EC (Executive Community) members in only two very specific cases: the proposal of a fourth platform -- something in addition to Java ME, SE, and EE -- and changes to the Java programming language itself. In both cases, Sun must vote yes for such JSRs to pass, in addition to the normal voting rules.

However, in all cases, the following is true: Sun must have the support of the majority of the community. If the majority of the EC does not vote in favor of a Sun JSR, then that JSR fails, meaning that the same rules apply to Sun that apply to any other JCP member.

Taken together, this creates a very healthy balance: Sun cannot do without the community, and the community also needs Sun.

What are the greatest sources of fear, uncertainty, and doubt (FUD)?

That's a tricky question. I think that there are some companies -- a few JCP members and a few nonmembers -- that don't seem to be motivated to acknowledge the success of the JCP. As Sun competitors, it appears difficult for them to credit an effort led by their competitor, because it probably makes them feel like they're giving credit to Sun itself. In part, this is understandable. Marketing professionals at these companies, just like their counterparts at Sun, are trained in pointing out what differentiates them, while a community-based effort like Java software and the JCP would prefer to highlight what makes us the same.

When a company outside the Java ecology tries to confuse its audience about Java technology and the JCP, that is expected. But for companies that benefit from this ecology, it's disappointing when they only manage to find negativity.

Sun's Jeff Jackson, vice president of the Java Developer Platforms Group at Sun Microsystems, remarked, "We need to credit the JCP and foster it, and emphasize how open it really is." Some people wonder how open the JCP really is. Can you clarify this for us?

It is much more open than many people realize. A look at the membership illustrates this. The majority of the membership is now made up of individual developers -- individual developers who have the same rights and obligations in the community as companies like SAP, Intel, JBoss, or Sun, for that matter. They can and do participate in expert groups, lead JSRs, vote in the yearly elections for the ECs, and actually serve on these committees. This is one of the things that makes the JCP unique.

All draft specs are publicly accessible to members and nonmembers alike. The voting by EC members during JSR ballots is public as well. And this voting is equally binding to Sun for the JSRs that it leads. Key JSRs are led by others than Sun. This is especially apparent in the Java ME space with MIDP (Mobile Information Device Profile) being led by Motorola and JSRs 248 and 249 being led jointly by Vodafone and Nokia.

How has J2SE 5.0 been received?

It appears that developers really like many of the new language features such as generics, annotations, autoboxing, and the concurrency utilities. Generics and annotations especially help developers to be more productive and develop higher-quality code: There is less boilerplate coding, less typing, and thus fewer chances to make mistakes.

I read recently that J2SE 5.0 is now also available for Mac OS X, which is good because there are many faithful Java developers on that platform. There is a nice overview of all the new stuff in J2SE 5.0.

How is the JCP doing lately? What is the biggest JCP news?

We're doing quite well. There's a slew of new JSRs. Day Software started version two of their Content Repository JSR (283) just after they finished the first one, JSR 170. TimeSys submitted JSR 282 to make some updates to the Real-Time Java specification. Nokia and Sun submitted JSRs 279 and 280 to bring some SOA and XML technologies to the Java ME environment -- it's exciting to see those technologies further enter the small device space.

"The big news, in addition to the new JSRs, is the continuing expansion of the JCP's membership into regions outside the Western world."     Onno Kluyt Senior Director and Chair of the JCP

Sun has started work with its Expert Group on JSR 277, the Java Modules API, which is expected to be an important JSR that looks at Java software functionality that most, if not all, Java developers use or depend on: archiving, JARs, and so on.

The big news, in addition to the new JSRs, is the continuing expansion of the JCP's membership into regions outside the Western world, which in itself is an indicator that the JCP is doing well.

Developers continue to find it relevant and want to be part of it. This expansion is important because increasing amounts of innovation happen in, for example, South America, India, and China. In 2005, the JCP has welcomed new members from each area, for example, SouJava from Brazil, Tata Elxsi from India, and recently China Mobile.

In a November 2004 interview, you said, "One of the things we're evaluating with the Executive Committees is actually the individual developer membership. Partly it's very good to have a majority of individual developer members, but at the same time it is something that needs to be done in balance because you need to balance individual interests with corporate interests." What has happened with individual developer membership since then?

I'm still watching this. As I mentioned, individuals now outnumber companies. So far, the cohesiveness of the community is absorbing this structural change. I've been watching with great interest what other communities do in similar situations. For example, I follow the Jini community. Their model is quite different from the JCP in that the Jini community chose to acknowledge individual interests and corporate interests as distinct and valuable. And so the Jini community membership is organized into a Commercial House and Individual House, and that seems to work very well for them.

You said, again in November 2004, "Another area where we may see change is how standards come about. Currently, you have roughly two ways of doing that: The first is to innovate, then standardize, and then implement, in that order, and the second general approach is to innovate, then implement, and then standardize. Now the JCP uses both methods, but the current discussion is about which is better." Is there a consensus now about which is better?

"Sometimes, experimentation is needed, in which case 'innovate, implement, standardize' may be a better way to come to consensus."     Onno Kluyt Senior Director and Chair of the JCP

Both have their pluses and minuses. "Innovate, standardize, implement" is a very powerful tool to create entirely new markets, like, for example, the application server market that was kick-started by the Java EE technology. In other situations, companies and developers will want to experiment first before deciding on a common approach.

Standardization, no matter by which approach, is always about agreeing on what areas not to disagree about anymore. Sometimes, experimentation is needed, in which case "innovate, implement, standardize" may be a better way to come to consensus.

Thus, the matter at hand is what set of changes to the bylaws or Internet Protocol (IP) policy of the JCP would be appropriate so that spec leads and Expert Groups can choose the model best suited to their effort. Whenever a community or standardization organization considers the IP policy, the discussion is always complex. The membership of the JCP represents companies, institutions, and developers worldwide, so balancing of rights and obligations in relation to all of our intellectual property requires great care.

What are the prospects of Microsoft or Red Hat joining the JCP?

In the Netherlands, Appie Happie, a famous cartoon character, often says, "Zeg nooit nooit" (never say never). We welcome both companies into our community. And certainly, Red Hat clearly has a keen interest in Java software, as you can see from their participation in the Objectweb community in the Jonas J2EE project. Also, many of their engineers participate in open-source projects like GCJ and GNU Classpath. I encourage them to join us and participate in the community that defines this technology.

How do individual developers and organizations go about joining?

Anyone who wants to join can go to the JCP membership page.

Are there any particular areas of expertise that the JCP needs help with?

I'd like the end-user companies at the receiving end of this technology that we, as a community, create -- the companies that use this technology to operate their business -- to be more active and represented.

I would love to see such a company run in the yearly elections for the ECs and get elected! By the way, the 2005 JCP EC elections are under way. And between October 4 and November 14, members are called to vote for the JCP EC seats that are up for ratification or election this year.

• The Java Community Process
• The Java Community Process (JCP) Highlights From the 2005 JavaOne Conference
• Star Spec Leads Program
• 2005 JCP EC Elections
• J2SE 5.0 in a Nutshell
• JOnAS: Java Open Application Server
• Red Hat
• Jini community
• Managing Transparency, Innovation, and Reliability: A Conversation With Jeff Jackson