Thought I’d put this in a separate topic!
I’ve seen a bunch of links describing how to use NIO to write servers. Are there any similar resources for making clients? Is NIO even worthwhile to use to write clients? ???
Thanks! 
NIO is not needed client-side for performance-reasons for networking.
One might argue it’s a better designed API than the old IO API and results in better code. It has however a steep learning-curve and a few obscure bugs (ask Blah3h).
If you have your own set of classes that handle all IO in your app, it might be better to make both client and server NIO, as you can reuse your code.
I wouldn’t even buy thast it’s a better API, other then the ByteBuffers which are nice but again only become a big deal when tryign to scale.
MNy advice is use java.net for your client unless you have a pressing reason not to.
Leaving aside the “is NIO a better API generally?” issue (since I believe it is, but the bugs have been upsetting me recently), I’d like to underline the above with a comment from the GDC a few years ago, which went something like:
“If there’s one thing you’re going to do in writing a networked game, make sure you re-use as much code from the server as possible in the client. At the very least, write all the code for both in the same file, preferably in the same method as often as possible. That does more to reduce protocol implementation bugs than anything else”
This was at a roundtable with circa 40 people, most of whom had shipped at least one networked game. Pretty much everyone chimed in to agree wholeheartedly with that.
Thanks for the help everyone!
I managed to scrounge up a really nice client/server NIO chat application sample (courtesy of PKWooster) using Swing for the client and now I’m all up and running! Everything sort of makes sense when you take a working example app and recopy it line-for-line! 
Now I just need to integrate JOGL into the client, which should be simple compared to the last day or so!
Truisms are generally wrong. ;D
HAving said that. IF I had written generic NIO handling code and reduced both clietn and server to calls through a common API, I might very well use it everywhere in my project. If not though then there is no value to having with NIO on both sides as the resulting code is likely to be as different as anything yould write with java.net.
It can save you a LOT of grief though to encapsulate your communications protocol and put it ina single place.
Yeah, fair enough. But it’s something I always bear in mind, and don’t make the decision to split them lightly.