Java non-blocking I/O
Java SUCKS! Platform independence doesn’t come with a high price. The last two days I have been trying to do asynchronous non-blocking I/O and got really frustrated. Moreover, I come to think that what I really wanted is simply not possible.
Correction - Java sucks LESS 
It’s not so well documented though…
I have a fully functional non-blocking IO for Java 1.4. It is multithreaded and it works great. What I tried first:
SOLUTION1
InputStream in = System.in;
while(wantToContinue) {
while (in.available() == 0) { try {Thread.sleep(sometime); } catch(InterrputerException ioe) {}; }
int bytesRead = in.read(buffer);
}
PROBLEM1 available() doesn’t report any data on end of file (which is reported by non-blocking read() returning -1), so there’s no way to detect this state.
SOLUTION2 Ok, what if we do the blocking I/O in a separate thread and simulate non-blocking I/O to the main thead (a simple producer-consumer programming exercise).
PROBLEM2 Once, a thread is stuck in a blocking read(), there’s NO WAY to terminate it. Closing the stream, interrupting or even terminating the thread has no effect whatsoever.
(PARTIAL) SOLUTION 2 The same as solution2, but assuming that we want to terminate the thread at the end of application, we can simply cat System.exit() in a finally{} statement.
Ugly like hell, but for our limited purposes, it works.
CONCLUSION Java is a nice programming language, but it’s of limited use for writing a simple Unix-like tools processing streams asynchronously (pipes, reading from stdin, etc.). java.nio (NEW I/O) doesn’t help here at all.
IMPROVED AND WORKING SOLUTION: Use Channels, but unstead of converting System.in to Channel, we use FileChannel fc = new FileInputStream(FileDescriptor.in).getChannel(); ByteBuffer b = ByteBuffer.wrap(tmpBuffer);
Now synchronous calls to FileChannes CAN be interrupted. BTW: it’s still not selectable though, which means we have to use another (ternimable this time) thread to do non-blocking ops.