<i18n dev> RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo

[Staffan Larsen]

On 28 nov 2012, at 14:30, Seán Coffey <sean.coffey at oracle.com> wrote:

> Staffan,
> 
> perhaps you can leave out the setting of security manager on the @run tags. Security manager can be added through the code as per current testcase.
> 
> @run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560
> 
> should work ?

This only works if I also add the TimeZone.setDefault(null); call from my webrev. The reason is that the security manager needs to be active when TimeZone.getDefault() is called without the timezone being cached. Since the first call to getDefault() will not have a security manager set, I have to reset the cached copy.

/Staffan

> 
> regards,
> Sean.
>> --- a/test/java/util/TimeZone/Bug6912560.java
>> +++ b/test/java/util/TimeZone/Bug6912560.java
>> @@ -26,7 +26,7 @@
>> /*
>>  * @test
>>  * @bug 6912560
>> - * @run main/othervm Bug6912560
>> + * @run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560
>>  * @summary Make sure that file path canonicalization in
>>  * sun.util.calendar.ZoneInfoFile works with the default security
>>  * manager.
>> @@ -37,9 +37,8 @@ import java.util.*;
>> 
>> public class Bug6912560 {
>>     public static void main(String[] args) {
>> -        // set the user.timezone property
>> +        // expected timezone
>>         String tzname = "Asia/Tokyo";
>> -        System.setProperty("user.timezone", tzname);
>> 
>>         System.setSecurityManager(new SecurityManager());
> 
> 
> 
> On 28/11/2012 12: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.coffey at 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.
>