On Wed, Jul 10, 2024 at 12:05 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> Le 2024-07-10 à 18 h 00, Archie Cobbs a écrit :
>
> So would you accept a solution to this problem in the java.sql package
> instead? For example by adding two new methods:
> java.sql.Blob.asByteBuffe
Le 2024-07-10 à 18 h 00, Archie Cobbs a écrit :
So would you accept a solution to this problem in the java.sql package
instead? For example by adding two new methods:
java.sql.Blob.asByteBuffer()
java.sql.Clob.asCharBuffer()
Yes, it would work for me if JDBC drivers provide their own
imple
On Tue, Jul 9, 2024 at 1:42 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
>
> 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
Le 2024-07-09 à 20 h 14, Archie Cobbs a écrit :
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.
Indeed, I wanted
Hi Martin,
On Tue, Jul 9, 2024 at 12:31 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> I was using a custom OutputStream implementation for getting the value of
> that field, avoiding any form of copy.
>
Gotcha - so in other words, you want a way to effectively "unwrap" the
o
Hello Archie, thanks for the reply.
Le 2024-07-09 à 18 h 17, Archie Cobbs a écrit :
The difference in the old vs. new behavior is the use of a 128k
temporary transfer buffer. So if I understand this correctly the
performance problem you are addressing (in terms of blown cache) is
not proporti
On Tue, Jul 9, 2024 at 10:51 AM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> JDK-22 has modified ByteArrayInputStream.transferTo(OutputStream)
> implementation for performing a defensive copy of the byte array when the
> destination is not trusted (JDK-8321053). However, I was
Hello
JDK-22 has modified ByteArrayInputStream.transferTo(OutputStream)
implementation for performing a defensive copy of the byte array when
the destination is not trusted (JDK-8321053). However, I was using the
previous implementation as a trick for reading the array without copy.
The reaso
