<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Le 2024-07-10 à 18 h 00, Archie Cobbs a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CANSoFxv+YcdB6VirRMHStD0Lme-df29ue78oAEis+xeT_Yss7g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>
<p>So would you accept a solution to this problem in the
java.sql package instead? For example by adding two new
methods:</p>
<div class="gmail_quote">
<div style="margin-left:40px"><span
style="font-family:monospace">java.sql.Blob.asByteBuffer()</span></div>
<div style="margin-left:40px"><span
style="font-family:monospace">java.sql.Clob.asCharBuffer()</span></div>
</div>
</div>
</div>
</blockquote>
<p>Yes, it would work for me if JDBC drivers provide their own
implementation. But it would not be exactly equivalent. A <font
face="monospace">Blob.asByteBuffer()</font> method would be
efficient when the JDBC driver loads all bytes anyway, but may be
expansive if the JDBC driver was really doing streaming. Maybe
some JDBC drivers do streaming only when the Blob size is over
some threshold (I didn't verified). Since a Blob can be very
large, wouldn't it be safer to avoid adding API that performs an
unconditional loading of all bytes? Unless the plan was to return
an <font face="monospace">Optional</font>.<br>
</p>
<p>By contrast, the <font face="monospace">ByteArrayInputStream.asByteBuffer()</font>
proposal never loads bytes that were not already in memory.
Therefore, it can be used in a more opportunistic way ("only if
all bytes happen to be in memory anyway, opportunistically use
them directly without copy"). Also, it does not require changes in
JDBC drivers, and could be used in contexts other than JDBC as
well.<br>
</p>
<p> Martin</p>
<p><br>
</p>
</body>
</html>