benefits of NIO

R

Roedy Green

I have been looking an nio trying to figure out how it works, and
hence where it would pay to flip over to it.

It uses an underlying InputStream. So if you read the whole
InputFileStream into a byte array in one i/o, NIO would do you no
good. It uses the same methods you do to get raw bytes.

However, if you used nio to read an encoded character file, you have
to do the decoding yourself, but the slick thing is, the output can go
to a CharBuffer. This saves quite a bit of overhead. decode does not
need to know in advance precisely how may chars the stream will decode
to. That saves a copy for trimming to size. And since it effectively
ends up with a char[] instead of a string, than saves yet another
copy. Bravo! The catch is CharBuffer is not quite as convenient as
String for processing.

I love the code to copy from one stream to another with a chunk buffer
in the middle. So simple compared with doing it yourself as I do in
FileTransfer. see http://mindprod.com/products1.html#FILETRANSFER.
The buffers magically handle the housekeeping to deal with short
reads, and the partial block at the end.

The inner loop for a copy is just:

inchannel.read( buffer );
outchannel.write( buffer );

There is no copying. You can even arrange that physical i/o happens
from the buffer array.

The basic idea is, ordinary i/o appears as a stream of individual
bytes or chars. NIO, i/o occurs in buffer fulls, and you are acutely
away of the buffer and can peek and poke it yourself. It is a little
bit like PL/1 based i/o.
 
S

Stefan Schulz

Not quite, sadly. You still need to flip() and compact() the buffer, so
your snipped becomes:

inchannel.read(buffer);
buffer.flip();
outchannel.write(buffer);
buffer.compact();
 
E

EJP

Roedy said:
It uses an underlying InputStream.

No it doesn't.
The inner loop for a copy is just:

inchannel.read( buffer );
outchannel.write( buffer );

There is no copying. You can even arrange that physical i/o happens
from the buffer array.

The inner loop for a copy is:

while ((count = inchannel.read(buffer) > 0 || buffer.position() > 0)
{
buffer.flip();
outchannel.write(buffer);
buffer.compact();
}

A copy operation is implicit in buffer.compact(). I don't know how else
physical I/O could operate other than from the buffer array, but perhaps
what is meant is that you can even arrange that the underlying byte[]
array of the buffer is on the JNI side rather than the Java side, so the
data doesn't have to enter the Java address space at all, i.e. it
doesn't have to cross the Java/JNI boundary twice.

You can also do inchannel.transferTo(outChannel); or
outChannel.transferFrom(inchannel) which is even simpler (but very
subject to OS and VM limitations, beware).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

NIO not so hot 15
Upload using java nio 10
BufferedReader vs NIO Buffer 6
Using NIO 2
Benefits of asyncio 31
NIO multiplexing + thread pooling 16
NIO enigma 4
nio limitations? 8

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top