I was wondering if you plan to address the review comment by David. If
that part gets addressed, I think the test case change is no longer
required. Otherwise, your change to the test program is fine with me.
Thanks,
Masayoshi
On 2012/11/28 21:59, Staffan Larsen wrote:
Did we conclude that my original change was good, or was there an alternative?
Thanks,
/Staffan
On 27 nov 2012, at 17:02, Seán Coffey <sean.cof...@oracle.com> wrote:
I suspect this test will fail with java agents too, say when doing code
coverage during test runs.
It might be better to just change the @run tag to specify -D user.timezone=
Asia/Tokyo, assuming this solves the problem too.
This test runs in othervm mode by default. Any java agents calling into this
would already have been causing an issue. Right ?
Is this outside the scope of the fix we need in 7155168 ?
regards,
Sean.
On 27/11/2012 11:02, Alan Bateman wrote:
On 27/11/2012 10:22, Staffan Larsen wrote:
Please review this fix for the java/util/TimeZone/Bug6912560.java test.
The problem with the test is that it fails when running with Java Flight
Recorder enabled. This is because JFR will call TimeZone.getDefault() when it
starts up, before the main() method is called. This will cause TimeZone to
cache the value so that when the test calls TimeZone.getDefault() it will get
the old value. The solution here is to reset the value in the beginning of the
test.
Webrev:
http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html
I suspect this test will fail with java agents too, say when doing code
coverage during test runs.
It might be better to just change the @run tag to specify -D user.timezone=
Asia/Tokyo, assuming this solves the problem too.
-Alan.
