Conformance Testing for Java ME

I'm back. I have no excuse for such a long delay in posting other than the usual "pressure of work." As it happens, this pressure has increased recently since I'm now managing the Java ME conformance test team as well as the Java SE team. I'll have much more to say about this as I become familiar with my new responsibilities, but in the meantime here are some initial thoughts on the difference between the Java SE and Java ME worlds.

Although Java SE is deployed on more than 700 million systems (mostly PCs and laptops but also servers, since Java SE is the foundation for Java EE) the number of different implementations is limited and a significant percentage of the installed base consists of Sun's implementations (for Windows, Linux, and Solaris). Mobile PhonesThese factors, coupled with the relatively homogenous nature of the specifications (more on this later) and of course the comprehensive nature of the conformance test suite (the JCK) that my team develops, ensure a high level of compatibility and interoperability between implementations.

Java ME is much more diverse. The primary market is cellphones (there are 1.2 billion Java-powered phones), but the technology is also deployed in other small and embedded devices such as TVs and set-top boxes (4 million deployments), PDAs, printers, and the new Blu-ray disk players. The Java ME portion of my team is also responsible for the conformance test suite for the Java Card smart card technology (2+ billion deployments and counting), but that's a subject for another article.

The mobile phone market presents an interesting contrast to Java SE. The market is much broader (more than 180 network operators and carriers) and much less homogenous. For a variety of reasons, the level of compatibility and interoperability between implementations of Java ME in mobile phones is lower than for Java SE. This problem is usually referred to as fragmentation.

As this article explains, there are three different types of fragmentation:

  1. Platform fragmentation, caused by variability in the specifications (different versions of specs, implementation-specific extensions, optionality, etc.)
  2. Implementation fragmentation (where implementations of the same APIs differ due to ambiguities in the spec, incomplete test suites, or just plain bugs).
  3. Device-level fragmentation (physical differences between handsets, such as screen size and color depth, input mechanisms, or the amount of memory present).

For all these reasons, it is difficult to "write once run everywhere" in the Java mobile phone market.

This issue is being addressed by a variety of initiatives from "umbrella specifications" that define common set of component APIs that should be implemented across all devices (see the Java Technology for the Wireless Industry specification and the more recent Mobile Service Architecture specification) to the development of standardized testing tools such as the Java Device Test Suite and the promotion of broader industry-wide testing programs such as the Unified Testing Initiative.

There are enough challenges here to keep us very busy for the foreseeable future, not to mention the changes that will result from the decision to open-source all our Java technologies. Change is good...

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Patrick Curran

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today