5

Is there any reason why I should use a XMLReader with the SAXParser? I'm seeing this kind of usage quite a lot:

        sp = spf.newSAXParser();
        XMLReader xr = sp.getXMLReader();
        LoginContentHandler uch = new LoginContentHandler();
        xr.setContentHandler(uch);
        xr.parse(new InputSource(in));

I always use the parser this way:

        sp = spf.newSAXParser();
        DefaultHandler dh = new LoginContentHandler();
        sp.parse(in, dh);

Any particular reason? Just wondering because my way is shorter, and I don't really see why I should use a XMLReader.

  • Tree vs Event based I believe: http://www.saxproject.org/event.html – Dr.J Apr 21 '11 at 12:45
  • Is SAX not always event based? –  Apr 21 '11 at 12:53
  • 1
    the XMLreader should be loading the file/stream into memory as a tree: `Finally, it is important to remember that it is possible to construct a parse tree using an event-based API, and it is possible to use an event-based API to traverse an in-memory tree. Have fun!` – Dr.J Apr 22 '11 at 02:28

1 Answers1

5

so to answer the question.

People using XMLReader are assuming that there is enough memory to store the file as a tree object and be able to traverse it at Log(n) time for searching.

On the other hand using SAX straight would mean you are using a event based plugin which would be in n time, but should leave a much less memory foot print.

It's a choice between space and speed.

note the reading about this from SAX's own page:

Dr.J
  • 1,220
  • 8
  • 9