About 5 things you don't know about Java common tools

Java common tools, such as parsing, timing, and sound

Many years ago, when I was a high school student, I had considered a novel writer as my career pursuit, and I subscribed to a Writer ' s Digest magazine. I remember one of the columns that was about "too small to save the thread", and the columnist described the kitchen storage drawer full of things that could not be sorted. I keep that in mind, it's just for the content of this article, the last article in this series (at least for now).

The Java platform is full of such "threads"-useful command-line tools and libraries that most Java developers don't even know, let alone use. Many of them cannot be categorized into the previous 5 series of programming categories, but try it anyway: some may be in the kitchen drawer of your programming.

1. StAX

In the millennium, when XML first appeared in front of many Java developers, there were two basic ways to parse XML files. The SAX parser is actually a large state machine that the programmer invokes a series of callback methods on the event. The DOM parser joins the entire XML document into memory and cuts it into discrete objects, which are joined together to form a tree. The tree describes the entire XML infoset representation of the document. Both parsers have drawbacks: SAX is too low-level to use, DOM costs too much, especially for large XML files-the entire tree becomes a behemoth.

Fortunately, the Java developer found a third way to parse the XML file, and by modeling the document as "nodes," they could take one at a time from the document stream, examine it, and then process or discard it. The "streams" of these "nodes" provide the middle of SAX and DOM, called "Streaming API for XML", or Stax. (this abbreviation is used to differentiate between the new API and the original SAX parser, which has the same name.) The StAX parser was later packaged into the JDK in the Javax.xml.stream package.

Using StAX is fairly straightforward: instantiate the Xmleventreader, point it to a well-formed XML file, and then "pull out" one node (usually with a while loop) to view. For example, in Listing 1, you enumerate all the targets in the Ant construction script:

Listing 1. Just let StAX point to the target.

Import java.io.*;
Import Javax.xml.namespace.QName;
Import javax.xml.stream.*;
Import javax.xml.stream.events.*;
Import javax.xml.stream.util.*;

public class Targets
{
public static void Main (string[] args)
Throws Exception
{
for (String Arg:args)
{
Xmleventreader XSR =
Xmlinputfactory.newinstance ()
. Createxmleventreader (New FileReader (ARG));
while (Xsr.hasnext ())
{
Xmlevent evt = Xsr.nextevent ();
Switch (Evt.geteventtype ())
{
Case Xmlevent.start_element:
{
Startelement se = evt.asstartelement ();
if (Se.getname (). Getlocalpart (). Equals ("target")
{
Attribute TargetName =
Se.getattributebyname (New QName ("name"));
Found a target!
System.out.println (Targetname.getvalue ());
}
Break
}
Ignore everything Else
}
}
}
}
}

The StAX parser does not replace all SAX and DOM code. But it will certainly make certain tasks easier. This is especially handy for accomplishing tasks that do not need to know the entire tree structure of an XML document.

Note that if the event object level is too high to be used, StAX also has a low-level API in Xmlstreamreader. Although it may not be useful without a reader, StAX also has a xmleventwriter, as well as a Xmlstreamwriter class for XML output.