JSR Watch

Digg This!

In last month's column Onno Kluyt announced that he would be handing over the role of JCP chair to me. I'd like to take this opportunity to thank Onno for all of the effort he's put into the JCP over the past several years, to thank the hard-working staff of the Program Management Office (who thankfully will not be moving on) for their support, and to introduce myself to the regular readers of this column.

I've worked at Sun for more years than I can even remember and have spent the last six years leading the team that develops conformance test suites (Technology Compatibility Kits or TCKs) for the Java SE platform. This work, together with an involvement in the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS), has prepared me for this new role.

Before I discuss what's happening in the JCP this month, let me start with a brief summary of my thoughts on the standards process.

The Value of Standards
I believe in standards. Standards make the world go round. You wouldn't be able to mail a letter or send an email message, drive a car or take an airplane trip, shop for food in a supermarket, obtain medical treatment in a hospital, watch TV or movies, enjoy a sports game, or do any of the other things that the modern world offers if it weren't for standards.

Developing Standards Is Difficult
The standards-development process is difficult. It can be slow, boring work. (You spend a lot of time discussing questions such as what the meaning of the word "is" is.) It's expensive (someone has to do all of that work). Although there are selfless individuals who devote their personal time to it, most standards work is funded directly or indirectly by corporations, who pay dues to the standards bodies and who pay their employees' salaries while these employees are spending their time on standards activities rather than working more directly on company business. Corporations don't fund this work because they are altruistic. They do so because they expect it to advance their commercial interests. The standards development process therefore involves a delicate balance between the private interests of the participants and the public interests of the broader community.

Conformance and Certification
While de-facto standards can be effective in the short run, for truly widespread adoption you need multiple compatible implementations. This is only possible if you have strong conformance test suites (and optionally, certification programs) to verify that these implementations actually conform to the specifications. Developing good conformance test suites is difficult and expensive (perhaps as difficult and expensive as developing specifications).

Community and Collaboration
Fortunately most participants in standards organizations recognize that the best way to advance their private interests is to collaborate with others in promoting the public interest. Good standards benefit everyone. It's not possible to develop high quality standards without involving those who will implement them and those who will be affected by them. A standards organization that is closed and exclusive will inevitably be less successful than one that is open and inclusive.

On the Shoulders of Giants
The standards world is one of interdependencies. It's seldom possible (and almost never desirable) to create a specification from scratch. Rather, specifications build on work that has been done before, referencing specifications that were developed by other standards bodies. It is therefore often necessary for standards organizations to collaborate with each other in evolving the specifications they share.

Open Source
The open source development model has clearly proven its value in recent years. The work of non-commercial organizations such as Apache and the GNU project, together with the success of Linux, have encouraged the adoption of open-source development processes and software licenses by many commercial enterprises and standards bodies. In an open-source world - where multiple incompatible implementations are likely due to the freedom to implement specifications in whole or in part - a standardization process and conformance testing are even more important.

Lessons for the JCP
These observations suggest that the following strategies for evolving the JCP over the coming years:

• Continued growth of the community - recruiting more members, particularly individuals, open-source groups, and end-users of Java technologies.
• Increased transparency - more involvement of the broader membership of the JCP and of non-members in the development of specifications.
• Increased outreach to and collaboration with other standards bodies.
• Further embracing of the open-source development model.

Updated JSRs this Month
As always, there's plenty of action on the JSR front. Here are some highlights:

JSR 225: (XQuery API for Java), led by Oracle, recently completed its Public Review Ballot. (This ballot takes place following a period of public review during which anyone - not just members of the JCP - may review and comment on a specification.) This JSR is a good example of the kind of collaboration between standards bodies that I discussed above, since it builds on the work of the W3C's XML Query Language Working Group. The JSR defines APIs that enable an application to submit queries that conform to the W3C XQuery 1.0 specification to an XML data source and to process the results of these queries.

The Proposed Final Draft Specification for JSR 284: Resource Consumption Management API, led by Google, was recently published. This JSR provides a framework for managing system resources such as memory, network bandwidth, and CPU time from Java in much the same way as these resources are managed by an operating system. This JSR also demonstrates how specifications build on each other (JSR 284 makes use of isolates as defined in JSR 121.)

On the Java ME front, a maintenance release of JSR 177: Security and Trust Services API for J2ME has been published by Sun. This JSR defines a variety of security services for Java ME devices. Once again, this JSR builds on a variety of other specifications for data security and encryption.

This is just a small sample of the JSRs that are currently active. See the Focus on JSRs section of the JCP home page for a complete list.

JCP Elections
It's that time of year again - we're preparing for the annual JCP elections. The work of the JCP is carried out by two Executive Committes: one for Java ME and one for Java SE and EE. Each year elections are held for one third of the membership of each committee. Therefore five ME EC seats and five SE/EE seats are up for re-election. As the founder of the JCP, Sun has the privilege and responsibility of nominating three of the five candidates on each EC. Nominees for these ratified seats must must be elected, of course, by the whole JCP membership in the same manner as nominees for the two elected seats. (The election process, together with all of the JCP's rules of governance, is defined in the JCP Process Document.)

This year the seats held by the following EC members are up for re-election:

On the ME EC:

• Ratified seats: NTT DoCoMo, RIM, Samsung
• Elected seats: Intel, Orange

  On the SE/EE EC:
  

• Ratified seats: Apache, Borland, Nortel
• Elected seats: Google, Red Hat Middleware

By the time you read this article Sun will have announced its nominations for the ratified seats. Voting for these seats begins early in October. Later in October those who wish to stand for the elected seats will announce their candidacies. (For more information about the voting process, including a full timetable, see the EC Elections 2007 page on the JCP website.) If you're not a JCP member there's still time to join before the elections begin. If you are a member, please vote!