Tr : System.arraycopy(...) equivalents for ByteBuffer/FileChannel

[Jeff Hain]

>ByteBuffers (...) were not designed for concurrent access


Not in general, but with readable HeapByteBuffers you can use
array()/arrayOffset() and play around with the byte array,
regardless of ByteBuffer's position (and even limit), so it
wouldn't be too much of an heresy to allow for other
position-agnostic treatments.




>I didn't quite get how FileChannel is an issue you can read
>and write to different parts of a file concurrently


You're right, with the current API, you can do whatever you want,
with only native copies (and just the required amount), both with
ByteBuffers and FileChannels contents.
I shouldn't have said anything about FileChannel, I just again
still had a bad solution in mind.


I said I was doing a "request for treatments addition",
but I should rather have said an advocacy or a plea.
What I still want to point out is that it's a pity (*) to have
to bother, either directly or through boilerplate that masks it,
with an instance-specific position, that gets in the way when all
you want to do is to play around freely with the data, such as
_just_ doing System.arraycopy-like behaviors requires non-trivial
boilerplate (not that it's hard, but there is room for bugs,
or inefficients implementations as I initially thought of).


To be more precise, the JDK API I'm thinking about would look like this,
with src and dst being either a ByteBuffer or a FileChannel (that would
make 4 methods, with ints/longs):
- void copyBytes(src,srcPos,dst,dstPos,n)
  (throws if limit()/size() don't allow for copy of n bytes,
  i.e. limit()/size() must not be modified concurrently)
On top (**) of that, one could easily add variants without
srcPos or dstPos argument, that would use instance's position
and update it, but some could be redundant with existing API.


Now I'll surely be fine with what I'll get done,
so I'll stop complaining :)




(*) Maybe this expression is too strong or subjective.
I mean a purely formal and objective pity, like if you had a computer
with everything but the 'e' key - which could be depressing though :)


(**) Or not, due to sendfile() not allowing to specify dstPos.




-Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20121012/bda75019/attachment.html