5.2. SAX1 Support
This section provides a brief overview of the SAX1 classes and migration support and of differences between SAX1 and SAX2. SAX1 is a subset of SAX2, so SAX2 is backward compatible. The only reason you might not want to have the SAX2 classes and interfaces in your class path is to avoid compiler warnings telling you when you're using now-deprecated APIs.
You shouldn't be using SAX1 APIs to write new code, but you may need to maintain or migrate older code written using these classes. As soon as possible, plan a maintenance step that involves switching to the new SAX2 versions of the APIs. This may include getting rid of some "home-brew" solutions for namespace support. (Some applications have found previously unsuspected bugs when they've made such changes; be alert!) This section has been written to highlight those changes.
If your parser supplier hasn't provided SAX2 support by now, it's probably also time to switch suppliers; however, you can use the ParserAdapter class to make these changes without changing parsers. In fact, if you're using ParserFactory to get the system default parser and haven't set a SAX2 XMLReader default, the reference XMLReaderFactory distribution will automatically wrap the SAX1 parser you've probably already identified using the org.xml.sax.parser system property. That is, just putting the SAX2 classes in your class path normally lets you start using SAX2 without needing to change your application configuration. (You can go the other way around with an XMLReaderAdapter if you want to use a more current parser while letting the application code continue to use older SAX1 APIs.)
You'll most likely be interested in these classes if you're working with an older, SAX1-based application or tool, such as the XT 0.5 XSLT engine. This includes applications written to the JAXP 1.0 API specification, which doesn't include SAX2 support. If so, the main difference you'll see is that SAX1 has a much simpler way of naming elements and attributes: it only needs to support the qName (qualified name) access style, not the namespace-aware style. This eliminates some opportunities for confusion, unless you're writing namespace-aware applications.
The following classes provide SAX1 support:
If your environment supports SAX1 but not SAX2, you can just add the SAX2 version of sax.jar to your class path, somewhere before the older SAX1 files. (Otherwise, you might get package-sealing violations, because the JVM might mix versions of the package. It may be best if you remove older copies of the SAX1 classes from your class path.) If you set the SAX1 org.xml.sax.parser system property to point to a SAX1 parser so that applications can rely on org.xml.sax.helpers.ParserFactory bootstrapping, you'll be glad that the SAX2 org.xml.sax.helpers.XMLReaderFactory knows how to use this property as a backup in case no default SAX2 parser has been configured.
Copyright © 2002 O'Reilly & Associates. All rights reserved.