You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2008/03/27 23:57:32 UTC

Re: [classlib][archive] Re: Delayed entry parsing

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


Re: [classlib][archive] Re: Delayed entry parsing

Posted by Tim Ellison <t....@gmail.com>.
Alexei Fedotov wrote:
> 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.

Rename.  Let's move one step at a time.

Regards,
Tim

Re: [classlib][archive] Re: Delayed entry parsing

Posted by Alexei Fedotov <al...@gmail.com>.
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 <t....@gmail.com> 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