[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-core-libs-dev
Subject:    Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its sp
From:       Ulf.Zibis () gmx ! de (Ulf Zibis)
Date:       2012-03-31 23:22:17
Message-ID: 4F7791A9.2000200 () gmx ! de
[Download RAW message or body]

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/%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
> The link to the start of the thread:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-March/009512.html
Good idea, to repeat these links.

-Ulf


[prev in list] [next in list] [prev in thread] [next in thread]