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

[David Holmes]

Hi Ulf,

On 29/03/2012 11:32 AM, Ulf Zibis wrote:
> David, this is great news. You like my approach. :-)

I just want to reach closure ;-)

> The separation in 3 files is intentional. I was thinking about of
> reusing TestCollection for future tastcases on other methods of
> AbstractCollection. But I'm not enough familiar with jtreg to argue, if
> this is possible.
> Similarly class Infrastructure could be reused over all JDK's tests. But
> personnally I would prefer to more and more use the JUnit framework. Is
> there already an existing example?
> How do you ensure, that all existing jdk subclasses of
> AbstractCollection are tested by the same patterns?

There are basically two sets of sets:
a) JCK tests: these are the official tests that should check that 
classes meet their specifications. They live "elsewhere".
b) Other tests: these live in the source repository in the test 
directory. These can combine additional "stress" tests, specific 
regression tests for a given bug fix etc. These are jtreg based.

So here we are writing a regression test to be put in the repository and 
executed using jtreg. I'm not an experienced jtreg  user or test writer 
so I can only look at other tests in the repository for guidance. But 
these classes are not going to be part of some larger more general 
all-encompassing test framework - at least not as part of this CR.

> I like your javadoc for setSizeSequence, but I have an addition, see below.

Ok.

> Have a nice flight,

Thanks, it's not quite imminent but I have a lot to do in the next 
couple of days. :)

David

>
> -Ulf
>
> Am 29.03.2012 02:36, schrieb David Holmes:
>> Hi Ulf,
>>
>> Thanks for the updates. This will take a little rearranging to get
>> into the right form I think - a single file is easier to deal with so
>> we could nest the TestCollection class.
>>
>> Regarding setPseudoConcurrentChronologicalSizeSequence, I think perhaps:
>>
>>    /** Sets the values that size() will return on each use. The next
>>        call to size will return sizes[0], then sizes[1] etc. This
>>        allows us to emulate a concurrent change to the contents of
>>        the collection without having to perform concurrent changes.
>>        If sizes contains a larger valuethan on last invocation, the
>> collection will appear to
>>        have shrunk when iterated; if a smaller value then the
>>        collection will appear to have grown when iterated
>>    */
>>    void setSizeSequence(int... sizes) {
>>         this.sizes = sizes;
>>         nextSize = 0;
>>     }
>>
>> Sean: can you massage this into a final version? If not I will try to
>> do so but I'm about to head out to JavaOne Japan and then am taking
>> some vacation time. Might be something I can work on on the plane :)
>>
>> Thanks,
>> David
>>
>> On 29/03/2012 4:48 AM, Ulf Zibis wrote:
>>> Hi David, Sean,
>>>
>>> I have made little changes to make understanding little easier, see
>>> attachment...
>>>
>>> -Ulf
>>>
>>>
>>> Am 28.03.2012 07:29, schrieb David Holmes:
>>>> Hi Ulf,
>>>>
>>>> I understand your point about ensuring we test
>>>> AbstractCollection.toArray but I find this revised test much harder to
>>>> understand.
>>>>
>>>> Also in the name setPseudoConcurrentSizeCourse the word "Course"
>>>> doesn't fit. I'm not sure what you were meaning here? Perhaps just
>>>> modifySize or emulateConcurrentSizeChange ?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>