JDOM vs SAX
For servers SAX is probably the way to go as it is fast and efficient. However, clients will be network or user bound (waiting for i/o) so the efficiency of parsing and representing data isn't very critical. In this case, developer efficiency rules.
If you haven't already, take a look at JDOM (www.jdom.org i think). It's basically DOM customized for Java so you can do stronger type checking and it follows Java library conventions for collections, iterators, etc. making it easier for most Java developers to use.
In the Jabber protocols you will be sending and receiving XML 'packets' which are sub-documents of the larger XML stream document. Each component in the client will handle each of these XML packets as relatively independent data. It is handy to develop clients with an event architecture with the XML packets serving as events. This plugs in well with the Swing event model too.
When you use SAX your events are the individual, low level XML information such as start tag, end tag, character data, etc. In most cases, you will end up building a class or data structure which is very tree like. In servers it is worthwhile to go through all sorts of contortions to make these XML packet objects as efficient as possible (sharing strings to reduce object churn, optimizing building and recycling of these objects, etc). On the client, this isn't such a big deal so you might as well let JDOM build you a generic JDOM document and use that as your packet object.
This doesn't eliminate the need for "framing" up these sub-documents so the XML parser (JDOM or SAX) treats them like separate documents. This takes customization of either the stream feeding the parser, the parser itself, or the JDOM document builder (or your own custom object builder class). If you read my book, you'll see how I did it with SAX, custom object builder classes, and custom packet objects. If I were writing a client library, I'd probably use a pull-parser like the embedded pull parser from www.enhydra.org,
and design a custom JDOM builder class.
Basically, my argument for using JDOM is laziness (i.e. lazy as a programmer virtue... see Perl, or old unix programming books for why this is such a great thing). Being lazy in the right ways usually leads to better libraries.
Jabber clients and foreign protocols
In general, Jabber clients don't need to do anything to support foreign protocols like AIM. Bridging to these networks and translating data formats are jobs performed by the server in most cases.
However, some systems like AIM have been blacklisting Jabber servers by watching how many users are logged in from a single IP address and blocking those that exceed some limit (a good sign that a Jabber server is at work). So some client authors have been writing their clients to hande foreign IM systems. However, AIM has been pretty good at doing things like asking for message digests of their client's DLLs and other things to make sure that you're only accessing AIM through AOLs client. It's kind of a losing battle unless you really want to devote a lot of time to fighting AOL.
Most other systems though tolerate some bridging and for those, there is usually Jabber server support (Yahoo for example). And truly open systems have excellent Jabber server support (IRC for example).