Tip: Achieving vendor independence with SAX

How to use SAX and a SAX helper class to achieve vendor independence

While newer XML developers are learning to achieve vendor independence with JAXP, SAX veterans have been vendor neutral for years. This tip explains how to use SAX and a SAX helper class to achieve vendor independence in your SAX-based applications.

Share:

Brett McLaughlin (brett@newInstance.com), Enhydra strategist, Lutris Technologies

Brett McLaughlin (brett@newInstance.com) works as Enhydra strategist at Lutris Technologies and specializes in distributed systems architecture. He is author of Java and XML (O'Reilly). He is involved in technologies such as Java servlets, Enterprise JavaBeans technology, XML, and business-to-business applications. Along with Jason Hunter, he founded the JDOM project, which provides a simple API for manipulating XML from Java applications. He is also an active developer on the Apache Cocoon project and the EJBoss EJB server as well as a co-founder of the Apache Turbine project.



01 March 2001

With the recent surge of interest in, and resources for, JAXP (the Java API for XML Parsing, which you can learn more about through the Resources section), you may have forgotten that SAX, DOM, and JDOM have been around for quite a while. In fact, many developers (maybe even you) use SAX, DOM, or JDOM without even touching JAXP.

While JDOM has a well-known, standard way of handling various parsers, and DOM has no facility for this at all prior to the DOM Level 3 version, SAX remains a bit of a mystery to many developers. Many programmers write SAX code that is neither portable nor vendor independent. The result is that they lock their applications into a specific parser -- sometimes a specific version of a parser. In this tip, I explain how you can make your life easier by using a SAX helper class to free your code from this dependence on a specific vendor class.

The foundation for all SAX programming is an instance of a SAXParser implementation. The most common means of parsing XML using SAX is simply to instantiate the vendor-provided implementation class. Listing 1 shows this methodology in action.

Of course, the problem with Listing 1 is that, in order to change parsers, you have to change the implementation class. And that might mean adding or removing import statements, and ... you get the idea. Suddenly, you are spending your coffee breaks modifying code and recompiling instead of drinking coffee! Lots of problems can result, to say the least. Changing from one SAX parser to another, however, shouldn't be such an ordeal. SAX provides developers a better option. Unfortunately, a lot of programmers miss out on it.

To make it easier to swap parsers, consider using the org.xml.sax.helpers.XMLReaderFactory helper class. This class provides a handy factory for taking a class name and then generating an instance of the provided class. If you have done much work with Java, you may recognize that this is similar to Class.forName(String className).newInstance(). So, instead of using code like that shown in Listing 1, you should code as shown in Listing 2.

In Listing 2, changing parser implementations simply involves changing a single class name. And that's a pretty safe change, since it involves merely modifying a String value. This is much better than the messy imports and code changes from Listing 1, wouldn't you say? The one drawback is that, when changing the parser, you still have to make some changes to your code. And that's not perfect. So, instead of hard coding in this string, you might want to use Java system properties to handle the class to load. This would allow specification of the parser class to your application either through a command-line argument (using the Java -D argument) or through a simple Java properties file. And, as if SAX weren't easy enough, the XMLReaderFactory class provides this functionality "out of the box." If no argument is specified to the createXMLReader() method, the method will look for a class specified as the value of the system property org.xml.sax.driver. You don't even have to do any work of your own! The code in Listing 2 then is modified to that in Listing 3.

Now, if you follow the method in Listing 3, your SAX code can hum along without even having to be recompiled, using different parser implementations as needed. Of course, if you're using JAXP, this approach isn't needed. But if you're a hardcore SAX person, then this tip will help you write code that's a little more portable a little more efficiently. And if you're using JAXP, you might want to check out my articles on the subject (see Resources). So code away, but be smart about it!

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into XML on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=XML
ArticleID=11981
ArticleTitle=Tip: Achieving vendor independence with SAX
publish-date=03012001