db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: Code coverage for client.net package
Date Fri, 25 May 2012 20:12:04 GMT
Mohamed Nufail <nufail56@gmail.com> writes:

> Hi,
> Going through the related Jira issue, I found that the changes have
> been introduced to get proper functionality for UDTs in the network
> client. The network client was required to behave similar to the
> embedded client when the columns contain java objects. For this
> reason, some of the functionality of the engine code was used in the
> client also.
> Initially, the two classes InputStreamUtil and
> DynamicByteArrayOutputStream were made common. But due to the
> possibility of failures, they were moved and now there are two copies
> in the engine code and client. But as already mentioned, in the
> network client, only a little part of these are being used in
> Request.writeUDT(). So as Knut mentioned the possible solutions would
> be making use of EncodedInputStream.PublicBufferOutputStream already
> existing in client.net package or using java.io.ByteArrayOutputStream. 
> I can't see any advantage of using one over the other except for
> PublicBufferOutputStream giving a direct reference to the byte array.
> But going through writeUDT(), it seems that it is not needed. So will
> it be ok to just use java.io.ByteArrayOutputStream?

Hi Nufail,

Thanks for sharing your analysis.

I think you're right that the extra functionality provided by
PublicBufferOutputStream isn't needed for writeUDT() to function

One small advantage of using PublicBufferOutputStream is that
PublicBufferOutputStream.getBuffer() returns the buffer directly,
whereas ByteArrayOutputStream.toByteArray() creates a copy of the
internal buffer. So by using PublicBufferOutputStream we save one
allocation of a byte array per write. I would guess this was also the
motivation for using DynamicByteArrayOutputStream instead of
ByteArrayOutputStream in the first place.

It's probably not a big deal, but for applications that write many UDTs,
using PublicBufferOutputStream and accessing the buffer directly might
take some load off the garbage collector and perform a little better.

Knut Anders

View raw message