I don't see the advantage of using byte[] honestly - using at the least
a wrapper object seems preferable. And if you're going to use a wrapper
object, why not just use ByteBuffer.
I'd prefer to introduce an interface type because ByteBuffer is
impossible to extend. I can do some quick and dirty coding to prove the
concept. How does it sound?
Defining an interface won't be helpfull... It will end up with almost
the very same implementation than the one we currenlty have (IoBuffer).
If you consider the reasons why IoBuffer was created (ie, loosy BB
interface, not expandable), I think that David's idea to define a helper
class seems slightly better.
For instance, BufferUtils.getLong( ByteBuffer ) or such methods can be
as convenient.
(That's a pity we can't extend ByteBuffer...)
Allocating a pre-sized buffer per connection can cause OOM when there
are massive number of idle connections.
+1
We could use composite buffer
in this case too because we can adjust the size of the buffer more
flexibly without causing reallocation.
Creating a BB is not costly in java 6. The idea would be to create BB
with the best possible size depending on the network capability (of
course, that mean we have some way to know what is the best size ...)
Gathering write is also a piece of cake if composite buffer is realized.
Of course it should be friendly with your suggested allocation mechanism.
I remember having read some post about gathering writes, where it is
explained that you should not take care of that on the BB level, as the
JVM will handle it by itself. Jean-François Arcan's post may be ?
<snip/>
Thanks for mentioning all possibilities. I'm leaning toward to my
original idea of providing byte array abstraction and buffer state
abstraction types because it can cover all cases you've mentioned.
Also, we can provide the sheer number of getters and putters for users
who like them anyway - it should end up with much simpler one monolithic
class - a way simpler.
That would be good ! And easier for people who want to enter the API to
maintain it !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
