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
On 28/03/2012 3:01 PM, Ulf Zibis wrote:
Hi Sean,
Am 26.03.2012 07:02, schrieb Sean Chou:
On Sat, Mar 24, 2012 at 5:09 AM, Ulf Zibis <ulf.zi...@gmx.de
<mailto:ulf.zi...@gmx.de>> wrote:
Will you please provide a jtreg style testcase with main method ?
Well, as I'm missing your agreement, that David's test
implementation doesn't guarantee to test the right toArray method
of AbstractCollection as I explained before, I'm afraid that
additional effort would be for garbage.
Every testcase or fix goes this way, like the first testcase I
provided. If your suggestion is valuable, I don't think it will be wasted.
Ok, here it is.
Aside, as the instantiation of (several) ConcurrentHashMap
subclassed test objects seems more expensive, I believe, my simple
TestCollection would increase the performance of the testcases.
What's the exact problem you want to fix in this case?
The execution time of jdk test cases.
-Ulf
