Tim, Actually I was thinking of benefits of extending ByteBuffer and returning ByteBuffer instance from the static method. Imagine a time when the same ByteBuffer would be used through the whole implementation starting from a memory mapped file till UTF-8 decoder input, and only relative positions would be passed around.
The reason why I did not use the ByteBuffer for return type was I was unable to find enough arguments for that complication right now. May be Alexey's MANIFEST would be the case when it would be convenient just to shift the last buffer position a over a nul character. Folks, I need your opinion to either rename the class or change return type to a slightly heavier one. Thanks! On Fri, Mar 28, 2008 at 1:57 AM, Tim Ellison <[EMAIL PROTECTED]> wrote: > Alexei Fedotov wrote: > > I have completed changes [1] based on your ideas of using > > ByteArrayInputStream child for exposing its underlying buffer as well > > as fixed few of my earlier TODO comments. I found the contract of the > > underlying buffer capturing close to ByteBuffer.wrap() method and > > named the class correspondingly. > > Nah, ByteBuffer.wrap(byte[]) would return a ByteBuffer. This is > reaching in and getting the implementation (i.e. almost the opposite). > > We need to rename it. How about InputStreamExposer#expose(InputStream). > > Regards, > Tim > > -- With best regards, Alexei
