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. >
