<div dir="ltr"><div dir="ltr">Hi Martin,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 9, 2024 at 12:31 PM Martin Desruisseaux <<a href="mailto:martin.desruisseaux@geomatys.com">martin.desruisseaux@geomatys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div><p>I was using a custom <font face="monospace">OutputStream</font>
      implementation for getting the value of that field, avoiding any
      form of copy.</p></div></blockquote><div>Gotcha - so in other words, you want a way to effectively "unwrap" the original byte[] array so you can access the whole thing at one time (random access), as opposed to just accessing it in online fashion as a stream of bytes.</div><div><br></div><div>It seems that the root of this dilemma is really the java.sql API. For example, you would think there should be a method <span style="font-family:monospace">java.sql.Blob.asByteBuffer()</span> (and <span style="font-family:monospace">Clob.asCharBuffer()</span>). Maybe adding such methods would be a more precise way to fix this.</div><div><br></div><div>In looking at this, I noticed that <span style="font-family:monospace">Blob.getBytes()</span> does not specify whether, when the entire array is asked for, a copy must (or must not) be returned. So you can't rely on that method for any particular behavior either.</div><div><br></div><div>Basically, the BLOB API seems clearly designed to allow the implementation to stream the data on demand if it wants to (which is good), but as a side effect it doesn't provide a way for the caller to guarantee avoidance of copying the entire array (if the implementation happens to not stream the data on demand).<br></div><div><br></div><div>-Archie<br></div><div> </div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>