Java Reference
In-Depth Information
System
.
out
.
println
(
"Person: "
+
new
new
String
(
ch
,
start
,
length
));
person
=
false
false
;
}
else
else iif
(
email
) {
System
.
out
.
println
(
"Email: "
+
new
new
String
(
ch
,
start
,
length
));
email
=
false
false
;
}
}
}
}
When run against the
people.xml
file shown in
Example 20-4
,
it prints the listing:
$
$ java -cp $js/target/classes xml.SAXLister
Person: Ian Darwin
Email: http://www.darwinsys.com/
Person: Another Darwin
Email: afd@node1.com
$
In version 2 of the XML DOM API, you can use the new
XMLReaderFact-
ory.createXMLReader()
. Incidentally, the SAX specification and code are maintained by
first to try loading the class defined in the system property
org.xml.sax.driver
, and if that
fails, to load an implementation-defined SAX parser. On extremely old versions, the Sun im-
plementation would simply throw an exception to the effect of
System property
org.xml.sax.driver not specified
. An overloaded form of
createXMLReader()
takes
the name of the parser as a string argument (e.g.,
"
org.apache.xerces.parsers.SAXParser
" or
"org.apache.crimson.parser.XMLReaderImpl"
). This class name would normally be
loaded from a properties file (see
Storing Strings in Properties and Preferences
)
to avoid hav-
ing the parser class name compiled into your application.
One problem with SAX is that it is, well, simple, and therefore doesn't scale well, as you can
see by thinking about this program. Imagine trying to handle 12 different tags and doing
something different with each one. For more involved analysis of an XML file, the Docu-
ment Object Model (DOM) or the JDOM API may be better suited. (On the other hand,
DOM requires keeping the entire tree in memory, so there are scalability issues with very
