Hello,
For some other libs test using randomness, we've been able to track down
and fix bugs only after a seed value was printed and usable for
reproducing the problem, see the history of:
* JDK-6854417: "testbug: java/util/regex/RegExTest.java fails
intermittently."
* JDK-8022224: Rare bug in JISAutodetect charset detected by
FindDecoderBugs test
The bad values which trigger the bug might only a very small subset of
the full space. For the latter bug which was tracked down once the seed
made the situation reproducible, see this comment from Martin in 2015 :-)
Sherman: Thanks for fixing this. I've observed this in the wild a
couple of times myself.
(Although flaky tests are annoying, finding actual bugs makes it so
worth it!)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034836.html
Please using the testing randomness library and the randomness jtreg
keyword. The keyword helps guide failure analysis.
Thanks,
-Joe
On 12/19/2018 7:15 AM, Martin Buchholz wrote:
On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs <roger.ri...@oracle.com> wrote:
Hi Martin,
It is also useful and conventional to print the seed of the random
so that if necessary it can be reproduced.
For many years, we've been using ThreadLocalRandom for testing, and that
does not allow setting a seed.
I remain unconvinced that saving a seed has value in the real world. When
a randomized test fails, running it with sufficient iterations has always
worked for me.
