Java Reference
In-Depth Information
Another thing that can help you understand a JSR is to draw class diagrams for the
interfaces and classes the JSR's packages provide—even if the JSR authors helpfully pro-
vide the diagrams anyway. If you can read through the description of a set of classes and
methods and produce a diagram of the relationships between those classes and methods,
you're well on the way to actually understanding how they work together.
A word of warning is in order, however. JSRs are in English, a natural language
fraught with nuance and uncertainty. Like any software system specification, it's difficult
to eliminate ambiguity when working with natural languages; worse, JSRs are often
meant to be descriptive of a number of actual implementations, and often aren't pre-
scriptive enough to cover all the possible ambiguities. JSR 135, which describes the
MMAPI, is a painful illustration; you need only consider the number of caveats I offered
in Chapter 16's “Capturing Media” section to realize that the JSR isn't the whole story.
Some JSRs actually try to address the shortcomings of other JSRs; the two JSRs describing
the MSA provide an example of JSRs attempting to mend flaws in previous JSRs.
Sun (and occasionally other companies) provide reference implementations (RIs)
to vendors for key packages, including the MMAPI. The RI is often the implementation
of the package in one or more JSRs that finds its way into the Sun Java Wireless Toolkit
and corresponding NetBeans Mobility Pack; Sun may also make the RI available to
vendors as a starting point on which to base their implementation. Additionally, Sun
also makes Technology Compatibility Kits (TCKs) available for many of these key
optional APIs; vendors can use the TCK's tests as a way to determine the degree to
which
their
implementation matches the RI. Of course, all of this assumes that the RI
is a perfect implementation of a perfect JSR that has no ambiguity (in either the eyes
of the RI implementors
or
you!)—a rather unlikely confluence of events in today's
software world.
The solution, of course, as I've urged you throughout this topic, is to implement
and test your assumptions about any API you use. Although it's extremely rare for an
API or a tool to be broken or nonexistent, it's entirely possible that some element of
the documentation around an API will not be quite clear (either to you or to someone
who based his or her implementation on the documentation). If you're learning a new
API, building a prototype of an application that uses key parts of that API is a good
way to both cement your understanding of the API and determine if it's as solid as it
ought to be. Furthermore, you can use that same prototype on different device targets
to explore any nuances of the device implementation of the API. As in most things,
there's really no substitute for experience.
Dealing with Fragmentation on Your Own
You may find yourself in the uncomfortable position of having to develop an application
using APIs that have no JSR; worse, the APIs may be different on different platforms. This
can happen, especially when working closely with device manufacturers or when relying
on cutting-edge features that the community just hasn't reached unity on. In that case,
