This month I'll discuss the evolution of the JCP, J2SE 1.5 or "Tiger", Java portlets, and a new JSR from Nokia and Siemens.

JSR 215, aka JCP Version 2.6
The Java Community Process is the only standards body with a version number! Currently, we're at 2.5 and hope to soon be at 2.6. Where are we now? About halfway between 2.5 and 2.6. Rule and regulation changes in the JCP happen through the JSRs. JSR 913 modified the JSR ballot voting rules, JSRs 99 and 171 led to JCP 2.5, and JSR 215 is creating JCP 2.6. This JSR just completed the Community Review and ballot. The Program Office together with the Executive Committees will now be working toward Public Review. A few of the things the group will focus on are clarifications around JSRs assigned to both ECs, a draft transparency plan for spec leads to use, and ironing out the mandatory TCK requirements. While the Community Review period has passed, the draft is still available on the Web site and you can send in your thoughts and ideas. Speaking of evolution, at the end of this year the JCP will be five years old. The Program Office will be at ApacheCon in November to celebrate. Now, on to the real work in the community!

A Tiger in Review
The three main Java platforms (J2ME, J2SE, and J2EE) are all done through the JCP. The coordination for these main releases takes place through so-called Umbrella JSRs. The actual API work for a new version of J2SE or J2EE does not happen in the Umbrella JSR. Instead the Umbrella JSR references the individual JSRs that specify new and updated APIs. Many of the JSRs that contribute to J2SE 1.5 or "Tiger" have just completed their Community Reviews. See JSR 176, the J2SE 1.5 Umbrella JSR, for a complete list of component JSRs. I covered a few of these JSRs in previous columns. Here I'd like to mention JSRs 3, 13, 199, 204, and 206. With "Tiger" the Java Management Extension specification becomes part of the J2SE distribution. JSR 13 adds floating point arithmetic to BigDecimal so that decimal numbers can be used for general purpose arithmetic without the need to convert to and from other types. The Java Compiler API enables a Java program to invoke a Java language compiler programmatically. JSR 204 further enhances the internationalization capabilities of the Java platform by providing support for the Unicode 3.1 standard. Unicode 3.1 defines characters that cannot be described by single 16-bit code points. Finally, there is JSR 206, which is developing JAXP version 1.3, an API for processing XML.

The Java Portlet Specification
This JSR, number 168, is co-led by IBM and Sun. The JSR resulted from a simultaneous submission of two quite similar JSRs individually presented by both companies. At the urging of the EC, IBM and Sun withdrew those individual JSRs and submitted a combined one, JSR 168. The JSR recently posted in short succession two Proposed Final Drafts, and it's very likely that by the time you read this column the JSR will be on the Final Approval Ballot. This specification builds on the servlet technology by defining the desktop metaphor for the aggregation of servlets and JSPs. It also covers security and personalization, and enables interoperability between portlets and portals.

JSR 228
Nokia and Siemens recently finalized JSR 195, Information Module Profile. This was quickly followed by the submission of JSR 228 that defines Information Module Profile - Next Generation. The technology is aimed at devices that want to support a MIDP 2.0 environment but don't provide any graphical display capabilities required by MIDP 2.0. JSR 195 first opened this market for Java-enabled devices, such as modems, metering, and home electronics. This created a strong desire for the advanced capabilities of MIDP 2.0. JSR 228 will focus on the domain security model, HTTPS and secure networking, OTA provisioning, and push architecture. The spec leads aim to finish the JSR in the late spring of 2004.

That's it for this month. I am very interested in your feedback. Please e-mail me with your comments, questions, and suggestions.