I don't think people will be confused; future is not a java API specific term, and they can see that the class does not implement Java's Future.

Regarding the java concurrency infrastructure, I don't think it fits our model or our purposes.  An ExecutorService will, as I understand it, take n tasks and distribute them across k threads (predefined or launched as needed), and return Future objects as a way of obtaining the results/status at a later date.  Resource contention is resolved on a first come, first serve basis, which for most background tasks (e.g. searching, sorting, indexing, etc) is what you want.  In this case, the queue and surrounding class are responsible for transmitting one or more simultaneous messages from one device to another; we use a single thread so we can control who can "jump the queue", which allows us to optimize for fast transmission of songs but still allow control messages to be sent immediately.  In our case, first come, first serve is the wrong model for contention access (e.g. access to the socket).  I'm all for using standard structures when they make sense, and if I'm wrong in my understand or assumptions, please let me know, but I really think we're talking about two solutions to two different problems.