Yes, this is quite easy to reproduce with jtreg-4.1-b06. I haven't tried the
latest sources but I don't think there's been so much change that this would be
different using the tip of the jtreg source tree.
It's not clear to me what the behavior ought to be if a single test file has
more than one @test tag. The jtreg tag spec [1] requires that @test be the
first token in the leading comment of the test file. This implies that @test
occurring later in the file has no significance. That the test is executed
twice under certain circumstances seems like a bug to me. Either the second
@test should be ignored, or perhaps it should be an error, not sure.
I can file a bug on this, if someone hasn't already.
s'marks
[1] http://openjdk.java.net/jtreg/tag-spec.txt
On 8/6/13 2:29 AM, Chris Hegarty wrote:
Hi Iris,
I'm not saying it is right, but this is the situation we found ourselves in.
It might point to a bug in jtreg, or just "bad" jtreg meta-data.
>: ls one
. .. HelloWorld.java
>: cat one/HelloWorld.java
/*
* @test
* @bug 8765432
*/
/*
* @test
*/
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World.");
}
}
>: jtreg -v1 one/HelloWorld.java
Passed: one/HelloWorld.java
Test results: passed: 1
Report written to .../jdk/test/JTreport/html/report.html
Results written to .../jdk/test/JTwork
>: jtreg -v1 one
Passed: one/HelloWorld.java
Passed: one/HelloWorld.java#id1
Test results: passed: 2
Report written to .../jdk/test/JTreport/html/report.html
Results written to .../jdk/test/JTwork
-Chris.
P.S. Note, the offending test has been fixed, and there is no issue in the jdk
regression tests affected by this.
On 05/08/2013 18:16, Iris Clark wrote:
Hi, Chris.
I also noticed this. Running the test explicitly seems to locate just the
first @test, while running in a batch (sometimes) finds the two! Not sure why.
If you execute jtreg with explicit file name(s), only those files will be
search for "@test" tags. If you use anything else, e.g. directory names,
then jtreg will search all *.java, *.sh, and *.html files searching for
"@test" tags. For the "sometimes" is it possible that one of the tests has
been somehow excluded (e.g. on a problem list) but the other one wasn't?
Thanks,
iris
-----Original Message-----
From: Chris Hegarty
Sent: Friday, August 02, 2013 3:19 AM
To: Paul Sandoz
Cc: Core-Libs-Dev Core-Libs-Dev
Subject: Re: Remove superfluous @test tags from
SpliteratorTraversingAndSplittingTest
On 02/08/2013 10:52, Paul Sandoz wrote:
On Aug 2, 2013, at 9:59 AM, Chris Hegarty<chris.hega...@oracle.com> wrote:
SpliteratorTraversingAndSplittingTest contains two @test tags. The second
of which does not specify that the test needs to run with testng. This
causes the test to fail, or have an error, when run as a batch with other
tests.
The second @test tag is just not needed, and the @bug should be moved to
the original @test tag.
Ooops that is my fault, thanks for sorting this out.
No Problem.
When i ran jtreg manually it did not barf, is there anyway for it to
validate the meta-data?
I also noticed this. Running the test explicitly seems to locate just the
first @test, while running in a batch (sometimes) finds the two! Not sure
why. It is also ok to have more than one @test, just in this case it would
need to specify testng.
-Chris.
