The approval of the JSRs within the JCP is a duty performed by the two Executive Committees. These are appointed bodies representing the members of the community. The ME EC oversees JSRs related to the consumer and embedded space while the SE/EE EC oversees JSRs for the desktop and server space. Together the two ECs also vote on the process-changing JSRs such as JSR 215. There are 16 voting members on each EC; Sun has a permanent seat on each EC. The 15 remaining seats have three-year terms with no limit to the number of terms a member can serve. One seat, one vote. Each year, in October and November, elections are held to appoint JCP members to the seats whose terms have come up. This year for the ME EC four nominated seats come up (Matsushita, Motorola, PalmSource, and Siemens) and two elected seats (BEA and Zucotto). For the SE/EE EC the names are Fujitsu, HP, IBM, Oracle (nominated), and Doug Lea (elected). Anyone who is a JCP member (corporate or individual) is eligible to vote in the elections and to serve on the Executive Committees. For more details go to http://jcp.org/en/whatsnew/elections. To see who is currently serving on the ECs go to http://jcp.org/en/participation/committee.

Profiling
There are two closely related JSRs quietly progressing through the process. JSR 163, led by Sun, specifies a profiling architecture for Java, and JSR 174, led by IBM, defines a monitoring and management specification for the virtual machine. Both JSRs are destined for inclusion in J2SE 1.5. JSR 163 will supersede the current Java Virtual Machine Profiling Interface (JVMPI). Both APIs will allow for dynamically enabling and disabling the profiling and monitoring functions and have design objectives to minimize performance overhead. Also part of the next release of J2SE will be JSR 133, which is revising the memory model and thread specification, and is currently in Community Review. The goal of the revision is to enable developers to create multithreaded applications that are reliable and correct. Some of the focus areas are volatile variables, final variables, immutable objects, and the semantics of threads and locks. The fourth JSR in this area that has progressed into Community Review is Doug Lea's JSR 166, Concurrent Utilities, another JSR that will be included in J2SE 1.5. By providing a standard set of concurrency utilities, the task of writing multithreaded applications will become easier and generally improve their quality.

Before moving off the topic of J2SE, it will be of interest to those writing software for desktop environments that JSR 97, JavaHelp version 2, has now posted its Proposed Final Draft, thus nudging closer to completion. The enhancements over version 1.0 include merging, multi-topic printing, JFC ToolTip support, and additional navigators.

Java APIs for Communications
Two JSRs of note in this environment: JSRs 164 and 165, both led by Matsushita/Panasonic, have entered public review. The first JSR defines the JAIN SIMPLE Presence API, and the second, the JAIN SIMPLE Instant Messaging API. SIMPLE stands for "SIP for Instant Messaging and Presence Leveraging Extensions" and is an IETF standard. SIP stands for "Session Initiation Protocol", also an IETF standard, and JAIN (still with me?) is the industry effort within the JCP defining Java APIs for the telecommunications and service providers markets. There are roughly 30 JSRs related to JAIN currently progressing through the JCP. JSR 164 provides a Java API to build support for presence servers such as subscription requests, authenticating and authorizing requests, and for presence clients, such as buddy lists, sending subscriptions and so on. JSR 165 provides a standard interface to exchange messages between SIMPLE clients in a secure and portable manner. Both JSRs are targeting both the J2ME and J2SE environments.

The J2ME Environment
The J2ME Web services specification, JSR 172, posted a second Proposed Final Draft. The specification defines an API to provide access from J2ME devices to Web services. Nokia's JSR 184, Mobile 3D Graphics, has also released a Proposed Final Draft. The Information Module Profile JSR, co-led by Siemens and Nokia, is now final. This is JSR 195.

Withdrawn JSRs
Sometimes JSRs are withdrawn by their submitters or spec leads. This can happen for various reasons, for example, a newer JSR subsumes the proposals of earlier JSRs or different directions are taken. Recently, JSR 159 was withdrawn in favor of JSRs 207 and 208. JSR 65 was withdrawn as the autoboxing facility proposed through JSR 201 takes precedence.

• From Within the Java Community Process Program
• Java Community Process 2.6: The JCP Evolves Again