java - Will FileChannel#write always write the whole buffer? -
(this related (or rather "opposite" of) would filechannel.read read less bytes specified if there's enough data? )
tl;dr :
will write whole buffer...
bytebuffer bytes = ...; fileoutputstream.getchannel().write(bytes);
...or necessary use loop this:
bytebuffer bytes = ...; while (bytes.remaining() > 0) { fileoutputstream.getchannel().write(bytes); }
?
due comment in answer, i'd ask whether there guarantees regarding behavior of writing buffer
filechannel
calling filechannel#write(bytebuffer)
.
just reference: documentation says
writes sequence of bytes channel given buffer.
bytes written starting @ channel's current file position unless channel in append mode, in case position first advanced end of file. file grown, if necessary, accommodate written bytes, , file position updated number of bytes written. otherwise method behaves specified writablebytechannel interface.
and documentation of overridden method, writablebytechannel#write(bytebuffer)
says
writes sequence of bytes channel given buffer.
an attempt made write r bytes channel, r number of bytes remaining in buffer, is, src.remaining(), @ moment method invoked.
suppose byte sequence of length n written, 0 <= n <= r. byte sequence transferred buffer starting @ index p, p buffer's position @ moment method invoked; index of last byte written p + n - 1. upon return buffer's position equal p + n; limit not have changed.
unless otherwise specified, write operation return after writing of r requested bytes. types of channels, depending upon state, may write of bytes or possibly none @ all. socket channel in non-blocking mode, example, cannot write more bytes free in socket's output buffer.
this method may invoked @ time. if thread has initiated write operation upon channel, however, invocation of method block until first operation complete.
parameters: src - buffer bytes retrieved
returns: number of bytes written, possibly zero
in above mentioned question reading filechannel
, there has been discussion in comments exact wording , interpretation of documentation. think crucial difference in documentation read method, documentation says
a read operation might not fill buffer, , in fact might not read bytes @ all.
in contrast that, documentation of write method says
unless otherwise specified, write operation return after writing of r requested bytes. types of channels, depending upon state, may write of bytes or possibly none @ all.
for me, means write operation on filechannel
will return after bytes have been written, because not specified otherwise in documentation (except statement return value may 0, artifact overridden method)
from tests file sizes of 80 mb (!), write operation always wrote whole buffer @ once. of course, test, , not sufficient profound statement. tried trace calls in related openjdk classes, these diverge different native implementations - , after all, should not necessary...
no, there no guarantees write() exhaust whole buffer. documentation try establish expectation implementations should write bytes in 1 go, takes care make no promises:
unless otherwise specified, write operation return after writing of r requested bytes. types of channels, depending upon state[1], may write of bytes or possibly none @ all.
filechannel.write() leaves room incomplete writes:
writes sequence of bytes channel given buffer.
bytes written starting @ channel's current file position unless channel in append mode, in case position first advanced end of file. file grown, if necessary, accommodate written bytes, , file position updated the number of bytes written. otherwise method behaves specified writablebytechannel interface.
so, while text implies full write general case , incomplete writes exception, leaves door open alternative/future implementations may not (be able to) adhere general case.
as point out, difference in approach read(). imagine because, @ time of consolidating documentation, known , intended implementations adhered general case of performing complete writes.
[1] reference non-blocking channels.
Comments
Post a Comment