Suppose I want to store many small configuration objects in XML, and I don't care too much about the format. The XMLDecoder class built into the JDK would work, and from what I hear, XStream works in a similar way.
What are the advantages to each library?
If you are planning on storing all those configuration objects in a single file, and that file will be quite large, both the options you've outlined above could be quite memory intensive, as they both require the entire file to be read into memory to be deserialized.
If memory usage is a concern (the file containing the XML will be very large), I recommend SAX.
If memory usage is not a concern (the file containing the XML will not be very large), I'd use whatever is included with the default JRE (in this case XMLDecoder) just to remove 3rd party dependencies.
I'd also prefer XStream as it is really easy to use and to extend. You can quickly start if you're going with the default setup. If you need to customize the behavior it has a very clean API and a lot of extension points, so you have really fine grained control over the things you want to tweak without interfering with other parts of the marshalling process.
As the XML that is created by XStream looks nice, manual editing is also simple. If the output doesn't fulfill your needs and the long list of available Converters doesn't contain the one you need, it's fairly simple to write your own.
A big plus is also the good documentation on their homepage.
Another suggestion: consider using JAXB (http://jaxb.dev.java.net). If you are using JDK 1.6, it comes bundled, check out "javax.xml.bind" for details, so no need for additional external jars.
JAXB is rather fast. I like XStream too, but it's bit slower. Also, XMLEncoder is bit of a toy (compared to other options)... but if it works, there's no harm in using it.
Also: one benefit of JAXB is that you can also bind partial document (sub-trees) with it; no need to create object(s) for the whole file. For this you need to use Stax (XMLStreamReader) to point to root element of the sub-tree, then bind. No need to use SAX, even for most large files, as long as it can be processed chunk by chunk.
Java also has a new utility class aimed at storing Key-Value paired sets typical to configurations. It is the old style but very simple and handy. This is done via the java.util.Properties class, a Map object with serialization options. This might be all you need unless you are storing entire objects.
I always find XStream very tempting, because it's so easy to get going. However, invariably I end up replacing it. It's really quite buggy, and its collection handling could use a lot of work.
As a result, I usually switch to JAXB. It's an awful lot more robust, it's pretty much bug-free, and a more flexible than XStream.
You should avoid XMLEncoder/XMLDecoder like the plague if you're going to be persisting a non-trivial number of objects or your system needs to be multithreaded. See http://matthew.mceachen.us/blog/do-not-want-xmlencoder-129.html for the grisly details.
If you must use XML, XStream is great. But ask yourself if you really need to use XML. Here's a serialization benchmark project that might turn you on to better solutions:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking