Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

[Sean Chou]

Hi Ulf,

    This is a regression testcase, there is no performance issue or future
refactoring.
    Please wait for David's comments.

On Sun, Apr 1, 2012 at 7:22 AM, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Hi Sean,
>
> thanks for your effort.
>
> Am 31.03.2012 11:43, schrieb Sean Chou:
>
>> Hi David and Ulf,
>>
>>   The new webrev is at: http://cr.openjdk.java.net/~**
>> zhouyx/7121314/webrev.03/<http://cr.openjdk.java.net/~zhouyx/7121314/webrev.03/><
>> http://cr.openjdk.java.net/%**7Ezhouyx/7121314/webrev.03/<http://cr.openjdk.java.net/%7Ezhouyx/7121314/webrev.03/>>
>>  .
>>
>>
>> About the fix, I remained the previous one.
>> About the testcase, I merged the 3 files into one.
>> During merging, there are 2 modifications:
>> 1. I added static modifier to the 3 classes, which are enclosed by class
>> ToArrayTest;
>>
> You do not need the indirection via main()...run()...test() if you have
> all in 1 file. This was only necessary to feature a general usability of
> InfraStructure. You can go back to David's 1 + 1 nested class approach
> replacing TConcurrentHashMapX by TestCollection and maybe rename realMain()
> to test().
> Additionally, loading 4 classes for 1 test would have some performance
> impact on the test run, which could be avoided.
>
>
>  2. I removed field TestCollection.fixedSize, which is never read after
>> Ulf fixed the bug in testcase.
>>
> This field would serve to "reset" the TestCollection to fixed default size
> without the need of new instantiation for later refactoring or testcase
> addition.
>
> As just discussed before, the doc for setSizeSequence() could be little
> more specific:
>  71         /*
>  72          * Sets the values that size() will return on each use. The
> first
>  73          * call to size will return sizes[0], then sizes[1] etc. This
>  74          * allows us to emulate a concurrent change to the contents of
>  75          * the collection without having to perform concurrent changes.
>  76          * If sizes[n+1] contains a larger value than on last n-th
> invocation,
>  77          * the collection will appear to have shrunk when iterated; if
> a
>  78          * smaller value then the collection will appear to have grown.
>  79          * When the last element of sizes is reached, the collection
> will
>  80          * appear size-fixed.
>  81          */
>
>
>  The link to the bug:
>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7121314<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121314>
>> The link to the start of the thread:
>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2012-**
>> March/009512.html<http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-March/009512.html>
>>
> Good idea, to repeat these links.
>
> -Ulf
>
>


-- 
Best Regards,
Sean Chou