No, they are not related, that is why NIO need be hacked to accomodate security issues. At the moment, I would not deploy LimeWire in a large organization since there is NO security at all. Adding some authentiacated Diffie-Hellman key exchange on top of secret-key encryption would ensure that two clients could transfer files to one another without the worry that a middleman could intercept the transmission. (Sender Y would have to agree to send content to user X of course.)

On the NIO mechanics, I am assuming that the "master thread" you speak of is used only to poll hardware for channels ready for I/O, not actually execute those tasks. If not, that thread is being VERY overwhelmed. One thread polling hardware and delegating work to a fixed-size thread pool is a much more efficient implementation. (Doug Lea's util.concurrent package has many executor implementations at gee.cs.oswego.edu) During the alpha and beta stages of the 1.4 VM, my working group was assigned to rigourously test NIO for months. We found bugs in the TCP side, yes, but they have been fixed in the 1.4.1 release. The only known NIO bugs right now appear when using DatagramChannels for UDP transport, which is of no concern here.

Some helpful literature:
1.) Concurrency:
Doug Lea's Station

2.) NIO tests:
PCES Project