Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / January 2006

Tip: Looking for answers? Try searching our database.

benefits of NIO

Thread view: 
Roedy Green - 22 Jan 2006 12:17 GMT
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.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Stefan Schulz - 22 Jan 2006 19:45 GMT
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();
EJP - 23 Jan 2006 03:10 GMT
> It uses an underlying InputStream.

No it doesn't.

> The inner loop for a copy  is just:
>
[quoted text clipped - 3 lines]
> 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).


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.