The JCP's annual elections for our Executive Committees (ECs) are now complete. As a reminder, during the first round the following members were nominated by Sun and ratified by the community:

• Nokia, Philips, and IBM for the Java ME EC
• Ericsson, SpringSource, and SAP for the Java SE/EE EC.

In the second round of the elections, during which all members are free to nominate themselves, voters had to choose two members for each EC. For the Java SE/EE EC the candidates were long-serving EC member Intel and three individual members: Werner Keil, Matthew McCullogh, and Shashank Tiwari. The winners were Intel (represented by Wayne Carr) and Werner Keil.

For the Java ME EC the candidates were Sony Ericsson (another long-serving member of the EC), Sean Sheedy (an individual), and Aplix Corporation. The winners were Sony Ericsson (represented by Christopher David) and Sean Sheedy.

So - in the open elections one corporate representative and one individual was elected to each EC. What lessons can we draw from this? First, our members obviously believe that the large corporations - those who fund most of the development work and the primary implementers of the technologies we develop - need to be represented on the ECs. (We shouldn't forget that just like open source communities, most standards development work is done by people who are paid by their employers to participate.) On the other hand, the election of Werner Keil and Sean Sheedy also indicates that the JCP's members feel the need for an "independent" voice - someone who can represent the broad development community, particularly developers who work independently or in relatively small companies. (We also shouldn't forget that 80% of the JCP's membership consists of individuals or non-profit organizations. So it's appropriate that we have at least one member on each EC whose primary purpose is to look out for their interests.)

Werner Kyle has 20 years experience in the industry during which he has worked for Nokia and BEA/Oracle. He runs his own consulting agency, contributes to open source projects, is joint spec lead for JSR 275: Units Specification, and has served on the expert groups of other JSRs.

Sean Sheedy has 20 years experience in the wireless industry. Currently an independent consultant, he worked for Sprint Nextel as its representative to the JCP until recently. He has been an active participant in several Java ME JSRs. Both Werner and Sean see their role as representing the independent developers - those who use rather than implement the technologies defined by the JCP. I'm sure they'll do this job well, and I'd like to welcome them to the ECs. I'd also like to thank our runners-up, and to congratulate Wayne Carr and Christopher David on their re-election.

The Latest JSR News
There are many JSRs worth noting this month - more than I have the space to discuss. (See the "Focus on JSRs" section on the JCP homepage or subscribe to our mailing list for full details.)

First, two JSRs made their final releases. JSR 293: Location API 2.0, led by Nokia, builds on the low-level location APIs defined by JSR 179, standardizing access to location-based services such as geocoding, mapping, and navigation. JSR 272: Mobile Broadcast Service API for Handheld Terminals, jointly led by Nokia and Motorola, defines APIs that enable client Java applications on mobile devices to receive, display, and interact with content received over a digital broadcast link.

Congratulations to the spec leads on reaching this important milestone.

Meanwhile, the spec leads for Java EE are extremely busy during the final months before the next version of the platform (Java EE 6) is released, and several of their JSRs entered public review. This is your opportunity to provide feedback - please do so.

JSR 299: Web Beans, led by Red Hat, enables EJB 3.0 components to be used as JSF managed beans. By unifying the two component models, programming for Web-based application development is dramatically simplified, enabling the rapid development of simple data-driven applications without sacrificing the full power of the Java EE 5 platform.

JSR 317: Java Persistence 2.0, led by Sun Microsystems, updates the Java Persistence API first defined in the Enterprise JavaBeans 3.0 specification (JSR 220), providing additional object/relational mapping functionality and query language capabilities.

JSR 322: Java EE Connector Architecture 1.6, also led by Sun, is an update to JSR 112 (J2EE Connector Architecture 1.5), which defines a standard architecture for connecting to heterogeneous enterprise information systems in both synchronous and asynchronous mode and provides pluggability layers for JMS (Java Message Service) and JDBC (Java Database Connectivity) providers.

Sun spec leads are also working to update two more Java EE specifications. JSR 314: JavaServer Faces 2.0 updates the 1.2 version of the JavaServer Faces specification (JSR 127), while JSR 315: Java Servlet 3.0 updates JSR 154 (Java Servlet 2.5) to support the Java EE 6 themes of extensibility, pluggability, and ease of development.

Two other Java EE-related JSRs, while not destined for immediate inclusion in the platform, reached the public review stage.

JSR 319: Availability Management for Java, led by recently elected EC member Jens Jenssen from Ericsson, defines APIs to enable availability management frameworks to supervise and control Java runtime units to achieve high availability. This important JSR will significantly enhance the clustering capabilities of the Java EE platform.

Finally, JSR 235: Service Data Objects is particularly interesting. It's the first attempt at developing a standard by having the JCP collaborate with another standards body (in this case OASIS). Technologies for SOA (Service Oriented Architecture) were initially developed by an industry consortium called Open SOA Collaboration. When its work reached a reasonable level of maturity it chose to standardize through OASIS, which has played a major role in developing enterprise-level business process standards. The Java aspects of this work are being standardized simultaneously through the JCP (as JSR 235). Although we recognize that "no standard is an island" - standards build on other standards, often from other standards-developing organizations (see, for example, the wide range of Java standards that build on the work of the W3C) - this is the first time that we've had such a close collaboration between the JCP and another standards organization. It's a good example of the kind of flexibility, openness, and collaboration that I hope we will see more of in the coming years.

Obviously, Java EE is alive and well.

Finally, let's not forget Java ME, where JSR 249: Mobile Service Architecture (MSA) 2, led by Vodafone & Nokia, also entered public review. MSA, which was originally defined in JSR 248 and released late in 2006, defines the stack of component JSRs (graphics, Web Services, location management, and so on) that you can expect to find on more and more mobile phones. This update to the spec incorporates new component JSRs and defines additional clarifications and requirements for implementing the JSRs in mobile devices. Please provide your feedback to the spec leads.

'); for(i = 0; i < google_ads.length; ++i) { document.write('
• '); document.write('' + google_ads[i].line1 + '
  '); document.write('' + google_ads[i].visible_url + '
  '); document.write(google_ads[i].line2 + ' ' + google_ads[i].line3); document.write('
'); } document.write('