gorithms that need only to scan through the data once and pull out information. But simple
scanning is all a parser can do. Parsers are not ideally suited for data that must be accessed in
random order, or examined more than once. To handle those situations, a program using only
a simple parser would need to build some internal data structure, which is a simple matter of
programming. But the document and Java object models already provide structured data,
which may be easier than defining new structures on your own.
This, in fact, is the real difference between using a parser and using a data marshaller. The
first two items in the list are pure parsers, and it is up to the application logic to handle the
data as the parser provides it. The second two are data marshallers: they must use a parser to
process the data, but they provide a data representation that more complex programs can use
in their logic.
So the primary choice regarding which technique to use is determined by how the application
needs to be written. If a program needs to make one simple pass through the data, then
simply using the fastest parser will suffice. Directly using a parser is also appropriate if the
data is to be saved in a simple, application-defined structure; for example, the prices for the
items in the sample data could be saved to an ArrayList , which would be easy for other ap-
plication logic to process.
Using a document model is more appropriate when the format of the data is important. If the
format of the data must be preserved, then a document format is very easy: the data can be
read into the document format, altered in some way, and then the document format can
simply be written to a new data stream.
For ultimate flexibility, an object model provides Java-language level representation of the
data. The data can be manipulated in the familiar terms of objects and their attributes. The
added complexity in the marshalling is (mostly) transparent to the developer and may make
that part of the application a little slower, but the productivity improvement in working with
the code can offset that issue.
The goal of the examples used in this section is to take the 20-item XML or JSON document
and save the item IDs into an array list. For some tests, only the first 10 items are needed.
This emulates something often found in the real world—web interfaces often return more
data than is actually needed. As a design consideration for a web service, that's a good thing:
the setup for the call takes some time, and it is better to have fewer remote calls (even if they
retrieve too much data) than to make many fine-grained remote calls.
While all the examples show this common operation, the point is not to compare their per-
formance directly on only that part of the task. Rather, each example will show how to per-
form the operation most efficiently within the chosen framework, since the choice of the