Migrate applications that use the XML parser for Java

Recently, the Apache Software Foundation announced the creation of the xml.apache.org project for Open Source XML solutions. As part of that announcement, IBM announced that it was donating the XML4J, XML4C and LotusXSL technologies to the xml.apache.org project. The parsing technologies have been renamed Xerces, and the LotusXSL technology has been renamed Xalan.

IBM is shifting its XML parsing development resources to work on the Xerces parsers. The objective is to use the Xerces code base as the foundation for XML4J and XML4C. This version of XML4J is based on the Apache Xerces version 2.0 codebase.

What's the difference between XML4J and Xerces?

Xerces has been internally tested at IBM, in addition to the testing that is done by the xml.apache.org project. The main JAR files names changed from xml4j.jar to xmlParserAPIs.jar and xercesImpl.jar, and from xml4jSamples.jar to xercesSamples.jar.

What part of the API is public, and what is subject to change?

API status must be defined before this question can be answered:

Public - This is the type of API that a typical client developer should code against. Attempts are made to fix severe bugs in this type of API. Much of this type of API (defined as public) has reached W3C Recommendation status or a similar status in xml-dev working group. The interface is not expected to change much.
Experimental - These interfaces and classes reflect the latest W3C specifications and SAX specifications from the xml-dev working group. Since these specifications are not finalized, the interfaces are subject to change. As some of these experimental specifications work through the working groups to the highest level, such as W3C Recommendation, they will be upgraded to the "Public" category.
Internal - These classes are considered to be internal to Xerces, even though they may be public and have public methods. They can be used by developers who have complex and specific needs, such as building their own XML Parser. However, note that the architecture is subject to change.

API Status API contents (packages, interfaces, classes and methods) Comments

Public DOM Level 1 interfaces and DOM Level 2 (DOM2) interfaces
The DOM2 interfaces have been implemented in the same interfaces as DOM1, but as new methods.

SAX Level 1 interfaces and SAX Level 2 (SAX2) interfaces
DOM L1, DOM L2, SAX1 and SAX2 Interfaces are stable.

Experimental DOM Level 3 (DOM3) and Core DOM Level 3 (DOM3) Abstract Schemas and Load and Save DOM L3 is in working draft status. XML4J provides a subset of DOM L3 support.

Internal All other packages are considered to be internal. The internal Xerces architecture may change.

API Status	API contents (packages, interfaces, classes and methods)	Comments
Public	DOM Level 1 interfaces and DOM Level 2 (DOM2) interfaces The DOM2 interfaces have been implemented in the same interfaces as DOM1, but as new methods. SAX Level 1 interfaces and SAX Level 2 (SAX2) interfaces	DOM L1, DOM L2, SAX1 and SAX2 Interfaces are stable.
Experimental	DOM Level 3 (DOM3) and Core DOM Level 3 (DOM3) Abstract Schemas and Load and Save	DOM L3 is in working draft status. XML4J provides a subset of DOM L3 support.
Internal	All other packages are considered to be internal.	The internal Xerces architecture may change.

As an Apache Open Source project, the Xerces community is very interested in your questions and feedback regarding the whole API, not only that part designated above as public.

If you have specific questions, patches, or feedback regarding the Xerces API or code, see the Apache Web site .

What APIs should I use for new development?

All new development should use the org.apache.xerces.parsers.* classes. The four compatibility parser classes have been replaced by these two classes:

org.apache.xerces.parsers.SAXParser 
org.apache.xerces.parsers.DOMParser

The control over validation has been changed to be a feature of the parser, rather then requiring separate classes.

The future direction for the parser instantiation classes is a parser instantiation API that results from the W3C DOM Level 3 effort, which is just getting underway.

To make sure your code is as stable as possible, use the interfaces specified in the Public section of the preceding table (for example DOM1 and SAX1). The table is updated periodically to reflect new interfaces and classes that are given Public status (for example, DOM2 and SAX2).

Is IBM making any additional support guarantees with XML4J?

IBM is not making any additional support guarantees for XML4J. In particular, IBM is not certifying that XML4J is Y2K compliant. XML4J makes no internal date calculations.

Migrating applications to use the XML4J 4.2.2 parser and the XSLT4J 2.5.4 transformer

JAXP defines a pluggability mechanism for a SAX and DOM parser via javax.xml.parsers APIs. Transformers are pluggable via javax.xml.transform APIs.

WebSphere Application Server Version 5.1 includes an XML4J 4.2.2 parser and an XSLT4J 2.5.4 transformer. To use a different implementation of JAXP in an application, package the parser and transformer in the application and change the class loader delegation to PARENT_LAST on the application or Web module.

It is recommended that applications do not use the parser or transformer implementation API directly, but that the applications use the JAXP API.

You can change an application to remove its dependency on the API in a previous version of the parser or the transformer from an earlier version of WebSphere Application Server. Package the JAR files in the application and set the classloader delegation mode to PARENT_LAST.

You must only recompile a Version 4.0.x XML application to migrate it to the Version 5.1 level.