<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    On 21/04/2025 17:46, Engebretson, John wrote:<br>
    <blockquote type="cite" cite="mid:4d239bc7086c49f6b56f9b3c741f13c6@amazon.com">
      
      <meta name="Generator" content="Microsoft Word 15 (filtered medium)">
      <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
        {font-family:Aptos;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Aptos",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}div.WordSection1
        {page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif"> 
            Following up on MemoryOutputStream, etc. – the conversation
            has considered a few alternatives:<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif"><br>
            1. Hide the new class behind
            ByteArrayOutputStream.unsynchronized()<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">2.
            Create a new public class providing views to OutputStream,
            Channel, InputStream<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">3.
            Something to do with an Object[] variant<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">  I
            would personally reject any code review that used
            “unsynchronized()” to describe this class, since that is
            only a minor property of the change.  I could live with
            “scalable” or something along those lines.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">  A
            new public class provides more capabilities than I initially
            proposed, but of course requires a new public class. 
          </span><span style="font-size:12.0pt;font-family:"Segoe UI Emoji",sans-serif">😊</span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">  The
            Object[] variant is interesting but I have no pressing need
            for it.  This probably gets a pin in it unless someone
            provides a use case.<o:p></o:p></span></p>
        <br>
      </div>
    </blockquote>
    <br>
    Maybe the two efforts should be separated.<br>
    <br>
    The removal of biased locking has shinned light on the
    synchronization in BAIS/BAOS. It's been there since JDK 1.0 and too
    risky to change. We need to decide whether to specify this long
    standing behavior. We also need to explore adding a factory method
    to both to obtain a <span style="font-size:12.0pt;font-family:"Aptos",sans-serif">stream
      that isn't thread safe. </span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">The
      factory methods can return a different implementation, in
      particular BAOS.</span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">unsynchronized
      (or whatever name it gets) </span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">does
      not need to collect the bytes in a contiguous array. So having a </span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">BAOS.</span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">unsynchronized
      may help with some of the scenarios that you are looking at.<br>
      <br>
      I think the PR proposing MemoryOutputStream is a bit premature and
      it will take a bit more work, and prototypes, to get a handle on
      the problem and help inform if a standard API makes sense. A sink
      that can collect an unbounded number of bytes could be fun to try
      to optimize for different usages. What isn't clear from the
      exploration so far is how to interface to other APIs. A method to
      return a byte[], like BAOS::toByteArray, is problematic when the
      number of bytes don't fit in an int. Maybe you have explored a
      segment like API or a </span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">cursor
      or consumer API to handle the bytes?<br>
    </span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif">
    </span><br>
    <span style="font-size:12.0pt;font-family:"Aptos",sans-serif">-Alan<br>
      <br>
      <br>
    </span>
  </body>
</html>