Java ME: Not Just for Cellphones
Most people probably think of Java ME in the context of cellphones, and with over 2 billion Java-enabled phones deployed that's hardly surprising. Many are probably also aware that Java ME runs in TV set-top boxes and Blu-ray disk players. (The recent announcement by Warner Bros. that it will release its high-definition movies exclusively in Blu-ray format seems to have guaranteed the victory of Blu-ray over the competing non-Java based HD-DVD format.) However, we should not forget that the "E" in Java ME stands for Embedded, and Java can also be found in a bewildering array of devices from printers and switches to medical equipment, cars, gas station pumps, and industrial robots. But this is just the beginning.

The Developer Days conference included several talks about the Sun SPOT (Small Programmable Object Technology) devices from Sun Labs. These are tiny wireless sensor boards that can be used to develop wireless sensor and actuator applications. They're programmed in Java since they include the Squawk Virtual Machine, which runs on the "bare metal" - there's no operating system. Although still experimental, they're already being deployed in applications as diverse as water-quality monitoring in Malawi and a geographic information system and wireless sensor network in the Panama rainforest.

As the SunSpot team explains:

One day everything of value will be part of the Internet...not just computers that talk to each other and exchange data, but virtually everything - all connected, all-communicating and sharing data, all the time. Cars, bicycles, refrigerators, astronauts, toys, even trees will collect and deliver diverse data to equally diverse devices (yes, trees - embedded with sensors that detect climate changes and animal movements).

You can read more about Sun SPOTs at www.sunspotworld.com/.

The Fragmentation Problem
Whenever a group of Java ME developers gets together there's bound to be a lively discussion about "fragmentation," and the Developer Days conference was no exception. The term "fragmentation" refers to the fact that despite Java's promise of Write Once Run Anywhere, it is often difficult to develop applications that will run on a wide variety of cellphones without very careful programming and extensive testing.

Fragmentation is actually an "umbrella term" that covers at least three distinct situations:

1. Platform fragmentation, where different APIs are present on different devices
2. Implementation fragmentation, where implementations of the same APIs differ between devices
3. Device-level fragmentation, where the characteristics of the devices themselves vary

The first two cases have direct relevance for the JCP. (The third is simply a consequence of the level of maturity of the small-device market and the rapid pace of change.)

Some platform fragmentation is inevitable given the enormous diversity of devices in the market and the different versions of specifications implemented on them. However, the nature and quality of the specifications is also a significant factor. The Java ME platform is not monolithic. Rather there are a large number of specifications that can be mixed and matched in a wide variety of configurations, and there are many optional or "conditionally mandatory" components such as Bluetooth or location services. Consequently it's not possible to predict which APIs will actually be present on any particular device.

This problem is not unique to Java ME - it exists in many other areas of the standards world - and the solution is well understood: an "umbrella specification" needs to be created that will define a minimum set of component APIs that must be included in compatible implementations and that will also eliminate optionality from the component specifications. In the Java ME space two such umbrella specifications have been developed: JSR 185: Java Technology for the Wireless Industry (JTWI), which was released in 2003, and the more recent JSR 248: Mobile Service Architecture specification, which was released at the end of 2006. The MSA specification (http://developers.sun.com/mobility/midp/articles/msaintro/) defines both a full stack consisting of 16 component JSRs and a subset stack consisting of eight JSRs. The first MSA-compliant phones are just beginning to reach the market.

Implementation fragmentation is a different problem, and it has two distinct causes. The first is again specification-derived. Many Java ME specs either deliberately or inadvertently contain ambiguities and omissions that lead to differences in implementations. This problem too is addressed by the MSA umbrella specification, which clarifies and tightens up the language, eliminates ambiguities, and adds requirements to the component specifications. The second cause of implementation fragmentation is bugs in the implementations, and this can only be addressed by more extensive testing. The test coverage provided by the relevant Technology Compatibility Kits (TCKs) needs to be increased, and since the TCKs by their nature do not cover all areas that could be tested (only what is specified), additional testing needs to be performed, ideally through a formal industry-wide certification program. The Java Verified Program (www.javaverified.com/about_uti.jsp) and the associated Unified Testing Initiative have begun to address this problem but much more remains to be done.

Java ME JSRs
A total of 77 Java ME JSRs have made some progress through the JCP since its inception and 42 have been completed. Twenty Java ME JSRs were active in 2007 (getting started, publishing drafts, going to ballot, or making final or maintenance releases).

A quick review of the active JSRs gives a clear picture of the breadth of technologies covered in the ME space: speech APIs (JSR 113), data synchronization (JSR 230), user interface customization (JSR 258), broadcast services (JSR 272), vector graphics (JSR 287), automotive telematics (JSR 298), event tracking (JSR 190), digital TV (JSR 242), and XML (JSR 280).

As I mentioned earlier, a number of additional Java ME JSRs made progress during the past month. The most significant is JSR 271: Mobile Information Device Profile (MIDP) 3 (http://jcp.org/en/jsr/detail?id=271), led by Motorola, which entered its Public Review period in December. This is a major revision of the "base" Java ME platform for cellphones. (MIDP is typically implemented on top of CLDC, which provides the low-level virtual machine, Java language, and utility and IO classes.) MIDP defines the higher-level APIs that make Java-enabled cellphones possible: networking, security, user interface, graphics, sound, and provisioning. The review period runs through March, so there's still time for you to comment on this important JSR. Other Java ME JSRs that made progress last month include:

• JSR 307: Network Mobility and Mobile Data API (led by Motorola), which is in Early Draft Review
• JSR 279: Service Connection API (led by Nokia & Sun) and JSR 293: Location API 2.0 (led by Nokia), which are in Public Review
• JSR 232: Mobile Operational Management (led by Motorola), which made a Maintenance Release

We should also not forget that those billions of cellphones would be nothing more than paperweights without the sophisticated back-end infrastructure that handles the switching, billing, subscriber management, service provision, and so on. Of course, these services are also run on Java. Last month there were three additional Java EE JSRs that made progress in this area. Two were from the indefatigable and prolific OSS/J Initiative (www.tmforum.org/OSSJ): JSR 254: OSS Discovery API (led by Nakina Systems) entered its Final Approval Ballot and JSR 210: OSS Service Quality Management API (led by Vallent Corporation) issued a Proposed Final Draft. The third, JSR 289: SIP Servlet v1.1 (led by BEA) passed its Public Review Ballot. This is an update to JSR 116, which defined a container-based approach to developing communication applications utilizing the Session Initiation Protocol (SIP) (defined by RFC 3621 [http://tools.ietf.org/html/rfc3261]). SIP is used to establish and manage IP-based sessions for applications such as Internet telephone calls and multimedia distribution and conferencing.

As you can see, Java ME is alive and well. For more details about the JSRs mentioned in this column and about the other activities of the JCP, please visit our Website (http://jcp.org/en/home/index).

Until next month...