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.zi...@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
