jmx-dev JDK-7120365 DiffHBTest.java fails due to ConcurrentModificationException
Stuart Marks
stuart.marks at oracle.com
Thu Dec 27 19:22:12 PST 2012
On 12/27/12 2:31 PM, Alan Bateman wrote:
> On 27/12/2012 18:19, Stuart Marks wrote:
>> It's true that one can omit the @run tag and single-file tests like this one
>> will get built and run by default. My advice, however, is to use the @run tag
>> even when one isn't strictly required.
> My comment was on the 3 x @run tags, the "@run clean" appeared odd. In any
> case, I agree that for anything other than single-class tests then it's really
> important to be explicit on the classes to compile. For single-class tests then
> I personally just keep it simple as jtreg will do the right thing once you add
> @test.
I agree that all three @run tags were unnecessary. From webrev.02:
29 * @run clean ConcurrentModificationTest
30 * @run build ConcurrentModificationTest
31 * @run main ConcurrentModificationTest
I'd suggest that lines 29 and 30 be removed, leaving only the "@run main" from
line 31. But in webrev.03 they've all been removed. The test will run and work
fine, until somebody adds an @build tag (or other similar tag), which will
cause the test to build but not run, but it will still be reported as passing.
This has happened before, and it'll happen again.
Alan, you've fixed a bunch of tests that were missing @run tags at least twice
in the past [1], [2]. I observe that this recent changeset [3] removed an @run
tag that was necessary to run the test. It's not quite the same pathology, but
it demonstrates that it's pretty easy to get the jtreg tags wrong.
Sorry Shanliang, I'm using your changeset as a springboard for this discussion
of jtreg tag style. I really do recommend that each test include an explicit
@run tag, since the tags are so easy to get wrong.
s'marks
[1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/d5ee8b871362
[2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6d934b1d9dd5
[3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/775b0050144a
More information about the serviceability-dev
mailing list