Java Reference
In-Depth Information
Sun and other vendors could provide additional features in a predictable and consistent
manner. The introduction of configurations, profiles, and packages lets Sun provide
versions of Java ME that meet the capabilities of specific classes of devices, and it lets
developers target those devices.
Contributing to Fragmentation and Unification
Sun licenses Java ME to an open market of platform and device vendors, many of whom
want to offer additional software or hardware features to differentiate their products. The
JCP addresses this by letting competing vendors work together to describe extensions to
Java ME (and Java as a whole). For example, prior to the FCOP, a number of handsets on a
few US carriers had proprietary, file system-access interfaces based on Java SE. While
nothing was architecturally wrong with these interfaces, the very fact that one carrier
supported handsets from multiple vendors with different interfaces to access files on
the file system was a big problem: if you wanted to achieve a wide market share on that
carrier with an application that required file-system access, you needed to write and
distribute multiple versions of your application. The FCOP addressed this by providing a
single API that all platform vendors offer. Now you only need to write your code using the
API that FCOP provides in order to run on any device that provides file-system access.
This solution works well for single API sets, such as the FCOP or the MMAPI, but
falls short when addressing the fact that different device vendors offer differing sets of
optional APIs. If you're writing a single application that requires only one or two optional
APIs, this may not be a large issue for you, but increasingly complex mobile applications
require the support of more than one or two optional APIs. These applications are often
at risk of not being able to gain the market share that can support their development,
simply because there's little clarity regarding which optional APIs platform vendors will
actually
support out of the plethora of those that exist.
An obvious solution to the problem is to apply the configuration/platform/package
model that Sun uses to describe Java ME versions to the optional packages, defining
new configurations and platforms. In essence, this is exactly what JCP members have
done through other JSRs. Some JSRs—such as the ones I'm discussing in this chapter,
which are JSR 185, JSR 248, and JSR 249—don't describe optional APIs; instead, they
describe collections of optional APIs and provide additional clarification as to the
acceptable behavior of specific optional APIs where necessary. In essence, these JSRs
attempt to unify the platform through the prescription that a set of optional APIs be
required in order for a particular name or label to apply. For example, as you'll see in the
next section, “Understanding the JTWI,” a JTWI-compliant device described by JSR 185
must include CLDC 1.0, MIDP 2.1, and WMA 1.1; it may also include MMAPI 1.1. Device
vendors can—and should—choose to meet the JTWI standard in order to make their
products palatable to the market, and carriers can require that devices meet the JTWI
standard prior to permitting them on their network.