For several months now a subset of the JCP's Executive Committees has been meeting as the Java ME Working Group to address Java ME-specific matters. In this column I'll focus on Java ME and on some of the issues that the Working Group has been discussing. (To follow our activities, check out our bulletin board at jcp.org.)

Fragmentation
Not surprisingly, the fragmentation problem is high on our list. In the Java ME space - much more so than in Java SE or Java EE - differences between implementations make it difficult to Write Once Run Anywhere. Developing an application that will run on many different cellphones requires very careful programming and extensive testing.

There are a number of reasons for this. Firstly, the Java ME specifications are much more modular than those for Java SE and Java EE, allowing many combinations and permutations of APIs. Even where two devices implement the same APIs, the implementations may differ for a variety of reasons: because the specifications are imprecise (either deliberately or through omission), because of different capabilities between devices, or simply because of bugs in the implementations.

Umbrella specifications such as JSR 249: Mobile Service Architecture (MSA) 2 address specification problems by reducing optionality and tightening requirements, but this is not sufficient. More comrehensive testing - above and beyond that performed by the TCKs - is also required.

Recognizing this fact, a new organization was recently formed by Orange, Sony Ericsson, Sun Microsystems, and Vodafone. JATAF (Java Application Terminal Alignment Framework) seeks to gather information about differences in Java ME implementations (whether or not these differences are caused by bugs), and to develop an open-source test suite that can be used by device manufactures and others to identify and hopefully eliminate these differences.

This effort can only succeed with the active participation of all Java ME developers. If you work with Java ME, please participate. Join the JATAF project at java.net, and report on your experiences with Java ME implementations. Implementation differences will be addressed by the development of tests and the clarification of specifications. Collectively we can all help to improve the quality of the platform.

Feature Phones and Smartphones
Another concern expressed by members of the ME Working Group was the widespread perception that Java ME is primarily a technology for low-end cellphones. While it's true that many (2 billion!) such phones are powered by Java ME, this is by no means all that the platform can do. Two JSRs that are expected to make their final releases soon intend to change this perception.

The Mobile Information Device Profile (MIDP) 3.0 specification adds new capabilities such as concurrency, inter-application communications, background processing, shared libraries, events, and improved user-interface components to enable the creation of Java applications that meet and exceed the capabilities of the most advanced smartphones..

Although JSR 249: MSA 2, addresses the fragmentation issue as discussed above, an equally important goal is to define a complete stack of APIs that will provide all of the functionality necessary to create fully-featured applications. The specification actually defines three profiles, for entry-level, mid-level, and high-end devices. Component JSRs include APIs for messaging, Bluetooth, contactless communication, user-interface development and deployment, graphics and multimedia, cryptography, and web services.

Cellphones implementing these two specifications will indeed be state of the art.

Beyond Phones
While Java's role in powering cellphones is widely recognized, we should not forget that the name Java ME stands for Java Mobile and Embedded. In addition to cellphones, Java can be found in printers and network devices, in vending machines and automobiles, and in consumer devices such as TV sets, set-top boxes, the Livescribe smartpen, and Amazon's Kindle. One of the most interesting and potentially influential uses of Java ME is in Blu-ray disc players.

Now that Blu-ray has won the standards battle with HD-DVD we can expect to see all optical-disc players migrate to the new standard within a few years. While the advatages that Blu-ray offers in storage capacity and high definition are well known, it's less widely understood that all Blu-ray disc players incorporate a fully programmable Java Virtual Machine with network connectivity. The Blue-ray disc Java (BD-J) specification is built on a combination of Java ME and Java-based TV sepecifications. BD-J provides a complete environment for the development of interactive and network-based video content. We don't yet know where this will lead, but the possibilities are endless. (Neal Young's Archives project is beginning to exploring this territory.)

Finally, a completely different application for Java ME is provided by Sentilla, who provide energy-management solutions for data centers by gathering data from tiny Java ME-based sensors that measure energy consumption and environmental factors such as temperature and humidity. This is a more focused approach than they originally adopted ("sensors everywhere") but it does suggest the way things will be done in the future. When it's possible to embed a Java VM with wireless communication capabilities in a device the size of a quarter then all sorts of possibilities open up.

For more news about Java ME and the variety of ways in which it is being used, visit the Mobile & Embedded Community at java.net.

Recent JSR Changes
JSR 316, the Java EE 6 platform specification, is almost complete. The Proposed Final Draft specification was published in October, and the spec leads hope to go to Final Ballot before the end of the year. Releasing a platform specification always requires careful choreography of the component JSRs, since all must be brought to completion simultaneously. One component of Java EE 6 that required particular attention is JSR 330: Dependency Injection for Java, which made its Final Release in October. Since this JSR was approved only in May, it holds the record for the fastest passage through the process. Congratulations to Google and SpringSource, the Spec Leads, and thanks to the members of the Java EE 6 team and to the Expert Group of JSR 299: Web Beans for their efforts in coordinating the two JSRs.

Congratulations are also due to Star Spec Lead David Nuescheler of Day Software, whose JSR 283: Content Repository for Java Technology recently made its Final Release. This update to JSR 170 defines an abstract model and a Java API for data storage and related services commonly used by content-oriented applications such as content-management systems and other applications that manage a mixture of structured and unstructured information.

For full details of other JSR chanages please see the jcp-announcements bulletin board on the new jcp.org web site, which replaces the previous JCP-interest mailing list. (Sneak preview: we'll soon be introducing RSS feeds at jcp.org, so you'll be able to have the latest news delivered to your mailbox.)

Wrapping Up
By the time you read this article the annual elections for the Executive Committees will be complete. Any changes in membership will be effective on 17 November 2009, and the first meeting of the new Executive Committees will be on 8 December. Finally, within the next few weeks we plan to roll out a new version of the jcp.org website. We haven't quite decided on the final feature-list, but please vist the site, and register if you haven't already done so.

Until next time...