Whilst this is obviously a comprehensive library, Java NIO is very easy to use. Gone are the days of trying to get networking to work well in Java.
You can write a very simple highly scalable and reliable http server in a few pages of code (There's a few such examples from sun, including https etc).
Obviously it depends on wether this is a core component of your app, if you need anything out of the box, or massive scalability or other optimizations that the library can't do easily.
My understanding is that it's basically a layer on top of select/poll/events/whatever. Right? select/etc... are a great way of whipping out static content, but if you have to stop to do some processing, you're going to lock things, unless you then spawn a thread, process, or something else to do concurrent work. What does one generally do with NIO?
Generally you make sure your network code is separate from any blocking activity.
For example, make a light "network plugin" that deals with your core functionality, then if it needs to go to DB, or do some potentially blocking action, have it call a "helper" which has it's own thread.
For instance, Mibbit handles around 7,000 connections at the peak of the day (3.5k in, 3.5k out). Those are all handled in a single thread. There's an additional thread that handles dns lookups, one to do database stuff. Each one of those just has a synchronized queue listing the jobs, each with a callback to update the network plugin with a reply.
The dns could actually be done asynchronously easily enough, but the gain wouldn't be worth it right now.
It depends on how lengthly other processing is going to be. Quite often you can separate the work up into chunks and just do a little each time (Kind of like your own time slicing). Or split it out into its own dedicated thread and have a job queue as above.
> Quite often you can separate the work up into chunks and just do a little each time (Kind of like your own time slicing).
I was going to mention this above, but this is one of the things that makes Erlang cool - it does that automatically, so that you just write your code, and it takes care of the scheduling.
You can write a very simple highly scalable and reliable http server in a few pages of code (There's a few such examples from sun, including https etc).
Obviously it depends on wether this is a core component of your app, if you need anything out of the box, or massive scalability or other optimizations that the library can't do easily.