Stefan Gmeiner wrote:
I don't think this is necessary. A 0 is also a valid data, so I see no
difference between a buffer not being zero'ed and a buffer containing only
0.
I would agree with you if we are not talking about C instead of java.
This is exactly the same problem. C or Java, the situation is the same.
<snip/>
Even the DirectBuffer class of
java.nio explicitly clears its data to 0 in the constructor.
We are not constructing new buffers. We are reusing them. You can still
fill them with 0 if needed.
For this
reasons I would assume that most java developers are used to having
implicitly initialized data.
IMO there is no advantage in receiving an uninitialised buffer. It
doesn't make sense to reuse a buffer with existing data.
It does : you don't have to reallocate a new one (this is important for
Direct buffers, I don't think it makes any difference with standard
ByteBuffers, and I'm even pretty sure that pooling standard BB might be
slower than requesting for a new BB)
This implies
that the client must always always reinitialise the buffer which
seems pointless as the buffer could be a new instance or the used
allocator is not the PooledByteBufferAllocator.
As you have a pretty strong semantic with BB, ie you have a capacity, a
limit and a current position which describe the area of the buffer where
you have valid bytes, unless you explicitely modify the limit, I don't
see how you can get the wrong data.
Due to this I feel it
would make more sense to assign the responsibility of clearing the
buffer to the PooledByteBufferAllocator.
We may add a new method which returns a zero'ed buffer, yes. It can be a
convenient method, even if I'm not convinced that it will be helpful ;)
Can you create a JIRA with a request for such a feature, so that we
don't forget about it ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
