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

Sean Chou zhouyx at linux.vnet.ibm.com
Sun Apr 1 03:08:28 UTC 2012

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/viewbug.do?bugid=7121314<http://bugs.sun.com/bugdatabase/viewbug.do?bugid=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

More information about the core-libs-dev mailing list