Java Reference
In-Depth Information
the set of packages a device may support, although configurations and
profiles are actually all the product of particular JSRs.
Java ME got off to a bumpy start - the realities and pressures of
business competition, largely due to the phenomenal rise of the mobile
games industry, led to a wide disparity in optional JSR support across
the set of available devices in the market. There was no standard set of
JSRs available, some implementations didn't comply with the defined JSR
requirements and some only offered partial compliance; it was extremely
difficult even to find out which JSRs were supported on any particular
handset. Sometimes irregularities occurred within the same family of
mobile phones from the same manufacturer, with APIs missing for no
obvious reason. Manufacturers would also add their own proprietary
APIs to allow non-standard functionality or extra functionality that wasn't
covered by the standard JSRs. While that addressed the short-term need,
such libraries had to stay around for compatibility reasons long after they
had been superseded.
The net result was a series of device-specific workarounds leading to
complex code forks and build trees for Java ME applications - particularly
games which would typically target hundreds of handsets at any one time.
Game development houses wrote entire libraries trying to work across
these heterogeneous environments and then had to work to recoup the
investments made. This unfortunate phenomenon is known as 'fragmen-
tation' and the 'write once, run anywhere' mantra became 'write once,
debug everywhere'. This had an extremely detrimental effect on the time
to market of Java ME applications and games.
1.5.4 Tackling Fragmentation
Something had to be done. The first attempt to tackle fragmentation
was JSR-185, Java Technology for the Wireless Industry (JTWI), which
specified a minimal level of optional API support for JTWI-compliant
devices. Release 1 of the JTWI was approved in July 2003 and defined
three categories of JSR: mandatory, conditionally required, and minimum
configuration. A handset that declares itself to be JTWI-compliant has
CLDC 1.0 or CLDC 1.1 as a minimum configuration and must support at
least:
•
MIDP 2.0 (JSR-118)
•
Wireless Messaging API (JSR-120).
If the device allows MIDlets to access multimedia functionality via
APIs, then the JTWI also specifies that the Mobile Media API (JSR-135) is
required (i.e., it is conditionally required).
JTWI also defined a number of implementation parameters for these
JSRs, including support for JPEG encoding, MIDI playback, the number of
