I'm not exactly sure what XML parser I should use when reading/writing XML for my application. I'm just starting to learn Java and I don't have the time to experiment with all the XML technology only to find that they don't suit my need. So I want to get some recommendation from other programmers based on their thought on the below requirements:

  1. I need to map XML elements to my Java class so that I can perform business logic on them.
  2. The XML will store cached data for an online application favouring client side data over server. That is, any information the user access on the server database will persist in the XML. When the app is online it will always retrieve data from the XML if available, or unless the state of the server database changed from another app session.
  3. Since the XML will essentially be an offline database, the reading and writing must be on demand. It shouldn't parse the whole XML file if it doesn't have to. That is, it follows some form of "filtering" convention - like a "where" clause.
  4. Continuing from point 3, it would be ideal to be able to limit the number of elements parsed with pagination.

You probably might see where I'm going with this. I'm looking for something similar to SQL, but for XML in Java. I'm not sure whether point 3 and 4 is possible - can a parser remember or hold on to the last position of the read operation?

1 Answer 1


I think the premise of your question - looking for something that resembles SQL - is quite wrong. While it's legitimate to try and keep your learning curve as short as possible, that approach could easily lead to you choosing quite the wrong tool for the job.

In any case, an XML parser is nothing like SQL. SQL is a query language for databases containing data that has already been parsed and loaded into the database in a form suitable for querying. The XML parser is like the database loader, not like the query language. You can query XML using XPath or XQuery, which both have similarities to SQL, but a query language is not a parser.

I would also question point (1). "I need to map XML elements to my Java class so that I can perform business logic on them". No, you don't. You can do it this way (in which case you want to use JAXB), and many people would be happy with that approach. In my experience it works well if the XML data is very simple and stable, if it has a schema, if the schema isn't going to change, and if the data is "data oriented" rather than "document oriented". If any of those conditions doesn't apply, using JAXB can be a nightmare. Even when they do apply, my recommendation is to use XML "end-to-end" (sometimes called XRX architecture) where all the business logic is done in XML-based languages such as XQuery and XSLT rather than in Java. That way you save all the effort of mapping data between two very different data models, the XML model and the Java model - the so-called impedance mismatch problem. If you know Java but don't know XQuery or XSLT then this approach might have a steeper learning curve, but you'll soon get payback from it.

  • I strongly agree, however I have seen one more (successful) implementation which is to use XSLT up to the java, where it gets transformed into a "stable" schema that is data-oriented, and then the JAXB is used. Commented Nov 16, 2014 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.