db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohamed Nufail <nufai...@gmail.com>
Subject Re: Code coverage for client.net package
Date Fri, 25 May 2012 19:26:35 GMT
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?

Regards,
Nufail.

On Wed, May 23, 2012 at 10:53 AM, Mohamed Nufail <nufail56@gmail.com> wrote:

> Thank you. I will go through those and come up with a solution.
>
> regards,
> Nufail.
>
> On Wed, May 23, 2012 at 9:22 AM, Bryan Pendleton <
> bpendleton.derby@gmail.com> wrote:
>
>> If only such little functionality is utilized, having those two classes
>>> is a waste. The new solution sounds much better.
>>>
>>> So shall I proceed with the suggested solution?
>>>
>>
>> Yes, I think that would be great!
>>
>> As Knut Anders observed, these two classes were created
>> fairly recently.
>>
>> You might start by reviewing the original change that
>> created these two files, and the JIRA entry that tracked
>> the discussion around that change, so that you have all
>> the background as to why those classes were created in
>> that fashion.
>>
>> Then you could explore the options that Knut Anders suggested,
>> or perhaps after your studies you will have a different
>> solution to propose.
>>
>> I believe that the change/JIRA information to examine is this:
>>
>> $ svn log InputStreamUtil.java
>> ------------------------------**------------------------------**
>> ------------
>> r899819 | rhillegas | 2010-01-15 13:32:14 -0800 (Fri, 15 Jan 2010) | 1
>> line
>>
>> DERBY-4491: Fix sealing violation which kills the AssertFailureTest on
>> runs against insane jar files.
>> ------------------------------**------------------------------**
>> ------------
>>
>> We'll be looking forward to hear what you learn as you study this.
>>
>> thanks,
>>
>> bryan
>>
>>
>
>
> --
>
> Mohamed Nufail
> Undergraduate,
> Department of Computer Science & Engineering,
> University of Moratuwa.
> Blog: http://www.nufailm.blogspot.com/
>
>
>


-- 

Mohamed Nufail
Undergraduate,
Department of Computer Science & Engineering,
University of Moratuwa.
Blog: http://www.nufailm.blogspot.com/

Mime
View raw message