Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

NIO: Impact on original I/O libraries  RSS feed

 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have just read the following in Manning's JDK1.4 Tutorial (Greg M. Travis) : "...to a substantial degree, the original I/O libraries have been rewritten to take advantage of the New I/O API"
I know, for instance, I can obtain a FileChannel from a RandomAccessFile, but does the above mean that the existing methods of RandomAccessFile have been reimplemented to internally use Buffers and Channels?
Is seek() implemented by a position() performed on an internal FileChannel? Similarly are read( byte[], int, int ) and write( byte[], int, int ) already implemented internally by NIO features?
Thanks, Barry
[ April 15, 2003: Message edited by: Barry Gaunt ]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting question. Looking into the source code it appears that no, RandomeAccessFile does not use a java.nio.channels.FileChannel internally for most of its operations. Instead, most of the key operations are declared as native. I believe that the native code implementations probably do use the channel implementations that are most appropriate for a given OS - and these are probably shared as much as possible between FileChannel and RandomAccessFile. However it's late, and I'm tired of trying to track down various bits of C code in the Community Source edition - so I'm just going to assume that I'm right, for now.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I noticed the new modes ( "rws", "rwd" ) allowed in the RandomAccessFile constructor. These are equivalent to FileChannel.force( true ) and FileChannel.force( false ). This implies to me that FileChannels are being used in the implementation of RandomAccessFile writes at least.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Again, not directly - all the write() methods ultimately call either write(int) or writeBytes(byts[], int, int) - both of which are native. So there's no java.nio.channels.FileChannel (a Java class) being used inside the code here. However the native methods may well be calling on the same native implementations as the FileChannel code, which includes the ability to force updates.
 
Ron Hitchens
Author
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to my contacts at Sun when I was writing the book, only the minimum necessary changes were made to existing code in java.io to support NIO. They didn't want to fiddle with working code any more than necessary. I believe that's wise engineering practice.
In the future they may retrofit java.io to use NIO where appropriate. But NIO needs to prove itself to be at least as stable as the conventional I/O classes before the implementations are swapped out. In my opinion, some NIO code still has some maturing to do before that should happen.
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Ron and Jim.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!