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