Sun's Java and XML APIs: What's the difference?

Author: Brett D. McLaughlin, Sr. (brett@newInstance.com), writer and editor, o'reilly media, Inc.

Brett McLaughlin has been using computers since the logo age. (Remember the triangle ?) In recent years, he has become a Java technology and XML
One of the most famous writers and programmers in the community. He used to implement complex enterprise systems in Nextel communications.
Technologies writes an application server, and recently continues to write and edit books in this area at o'reilly media, Inc. In his new book
In Head rush Ajax, Brett and best-selling author Eric and Beth Freeman have brought Ajax an award-winning innovative method.
Head first. His last book, Java 1.5 Tiger: A developer's notebook, is the first available version.
Java and XML is still an authoritative book using XML technology in Java.

Review the ancient JAXP

For programmers who are new to Java and XML (or programmers who are new to XML only through sun and j2se), it is necessary to briefly review
JAXP. At that time, JAXP was the third-ranked API in the Java and XML fields, and its popularity was second only to that of SAX (Simple API for XML) and
Dom (Document Object Model ). JAXP's goal is very simple: to make the use of Sax and Dom easier, especially in the field of vendor-neutral.

JAXP is a package API

Initially, JAXP was designed to provide convenience and vendor neutrality to Sax and Dom. Based on this, JAXP has never thought of replacing sax or
Dom; in fact, JAXP has some methods in earlier versions. getxmlreader () and getdomparser () are two of them.
Obviously, the existence of these methods indicates that the author of JAXP wants developers to use JAXP and then operate on the underlying Sax and Dom implementation classes.

It is worth noting that although JAXP
Many features have been added over the years, but these two methods have never been modified. Some may say that this is only for backward compatibility considerations, but it does reflect that JAXP has never intended
Replace it with sax or Dom. JAXP encapsulates them, so developers do not have to use a large amount of vendor-specific code to call sax or Dom.

JAXP provides vendor neutrality

In earlier Java and XML programming, there were a lot of XML Parser (originally xerces and xml4j, sun's
Crimson, Oracle's XML parser, and some parser that people have never heard of today .) When we compile
For applications that collaborate and interact with each other, you need to connect the sax and Dom APIs to these parser implementations. The common method used is to inform the sax or
Dom, a bit similar to the following method:

Parser = new org. Apache. xercers. parsers. saxparser ();

Note: I intentionally used the older SAX Parser interface, which is the old sax 1 parsing class and is used by everyone when JAXP becomes a problem.

JAXP introduces a javax. xml. parsers. saxparserfactory
System attribute, which allows us to specify the parser factory implementation (the factory provides the parser we want to use ). You can use a system. setproperty ()
System Properties can also be specified by the JAXP. properties file in some locations (essentially, any location in the application class path ).

Regardless of the method used to specify this property-or its corresponding Dom attribute javax. xml. parsers. documentbuilderfactory
-Avoid any class names in the parsing code. This is also JAXP
Primary Cause: prevent such information from being directly put into the code. You can easily modify attributes by Changing Attribute values, or even create multiple JAXP. Properties
Files are used for different parser implementations and switched as needed.

JAXP status quo

JAXP launched by Sun
You can stick to your own opinions or even deny the value, but this has no practical significance. It is truly practical and worth discussing: JAXP
What are roles today? And how people are using it? Today, all Java distributions include JAXP without exception. Obviously, Java EE (j2se
And Java platform, Enterprise Edition 5), Java platform and Java me (Java
Me) not included. About 95% of Java and XML developers are using JAXP.

JAXP as an alternative to Sax and Dom

Over time, JAXP no longer encapsulates Sax and Dom, but gradually replaces them. Now, we need to remember that JAXP is not a real parsing.
API (when the operation of the sax or DOM parser is required ). Therefore, JAXP can never replace the sax or DOM function. However, it can be used in practical applications.
Instead, developers can stop using methods or classes in the sax package (Org. xml. Sax) or DOM package (Org. W3C. DOM.

One way to verify this is to ask the developer. Because sun is promoting its own APIs (which can be understood in this way), and JAXP and the current version of Java Technology
"Bound" together, so many developers use JAXP to access XML. Naturally, they started to learn how to use JAXP, and even most of them have mastered sax.
And Dom developers also think JAXP is more useful. In fact, many developers do not fully realize that sax and Dom are the foundation of JAXP!

All of these make Sax and Dom gradually fall out of sight in the light of JAXP. For contenthandler and
The talk about domimplementation has become yellow yesterday, or at least a fairly high-end Java and XML programmer will know this. This even works with 5
A year ago, the competition was very different. At that time, JAXP was still in the evolution and initial stage. In addition to JAXP, developers usually have at least
In most cases, there are two preferences ).

Are more functions added or are they maintained as they are?

However, what is more important than competing with each other is that some people even use only JAXP-instead of using Sax and Dom directly, or those APIs attached to JAXP.
-This greatly limits the XML programming and parsing functions. Because JAXP is indeed just a package API (no matter how people use it), it cannot use SAX and Dom
Any options provided. Although we can set parser features and properties on JAXP and handle content and basic error handling
In particular, it provides a large number of syntax-related events (DTD and mode) and more advanced lexical events (such as processing commands ). The only way to access these events is to directly operate the sax
Xmlreader interface.

Remember, I do not advocate killing JAXP. We can use JAXP as its original purpose-access the parser without directly processing the vendor parser class in the code-
Then use getxmlreader () of JAXP to access the interface for obtaining sax xmlreader. In this way, you can easily directly operate the sax-
However, we need to first understand how to operate the xmlreader interface.

All of this shows that JAXP has added some features-vendor neutrality, convenience, and helper methods-
But you can actually remove the content. If developers rely too much on JAXP (which has already become a problem), they will easily forget or even fail to realize JAXP.
A large number of functions in Sax and Dom are not made public. Therefore, although JAXP was originally used to provide functions, it actually reduces Java and XML programmer tools.

Open source code problems?

I leave this question to the end of my discussion mainly because it involves ethics, legitimacy, and a variety of content that will make most programmers feel boring and boring. It seems that this is not enough. Open Source Code also involves philosophy.
. In short, I want to know whether Sun-although he has always put the law first-violates the legal spirit (Open Source and community ). When they
As a cornerstone, I started to add features in JAXP. I wonder why they didn't integrate these features into sax? In JAXP
Adding Methods to call these new functions (that is, most of their APIs) is also completely feasible. But cannot these functions be submitted to the sax API as a whole?

In fact, if JAXP is more practical than sun
I hope we believe that (to be honest, I don't have to discuss its practicality), So why don't they provide these features to us. At least sometimes we tend to use SAX separately, instead of having
JAXP. To avoid any possible confusion, we still choose to use Java technology, so sun uses
JAXP) providing these features will not lose any business (this is even a joke, just as sun no longer sells Java
Technology ). In addition, although this problem is quite subtle, it is worth thinking: If JAXP provides such great value, isn't some of the value assigned to the underlying API?
? JAXP will still benefit from the easy conversion between Sax and Dom, but it will be a great pleasure for the XML community.

Conclusion

I don't want to make an impassioned comment here (but I don't mind some readers doing this on the Forum), but I still want to question JAXP-and others of the same nature
API-and its evolution from a package API to an all-around parser API. I think JAXP has buried Sax and Dom.
Its own value has not been converted back to any meaningful value. I'm happy that sun uses JAXP as an encapsulation layer for vendor-neutral, and keeps parsing methods and behavior firmly in XML
The Parser and API supplier are in the Territory.

Of course, sun did not ask me for advice, and Scott mcnealy certainly never heard of me.
We can't do anything about it. However, if you are a Java and XML programmer, this will at least give you doubts about the use of JAXP-
This is their intention. If the programmer needs to (re-) Learn Sax and Dom, we will start to use them wisely.
JAXP, in fact, is designed to better write applications, because we can operate XML documents at a lower level, and it is more convenient. Then, even Scott
All of them will notice the excellent applications we have compiled, isn't it? So you tell me: Does this mean anything?