From Masayoshi.Okutsu at Sun.COM  Mon Mar 10 01:18:24 2008
From: Masayoshi.Okutsu at Sun.COM (Masayoshi Okutsu)
Date: Mon, 10 Mar 2008 17:18:24 +0900
Subject: <i18n dev> tzdata lookup path support
Message-ID: <47D4EED0.90604@sun.com>

Sorry again for taking time. Finally, I've spent a reasonable amount of 
time to deal with the issue. (I've change the subject because "Using 
system tzdata" keeps people confused that the proposal is to utilize the 
native Olson binary tzdata on Linux.)

I made the following changes from your proposed changes.

    * The default value of the "sun.zoneinfo.dir" property is "". This
      default value can be overridden at the build time by specifying
      ALT_ZONEINFO_DIR, e.g. "make ALT_ZONEINFO_DIR=/usr/share/javazi".
      This is because Sun's tzupdater tool is confused with the property
      setting if there are valid tzdata files under the directory
      specified by the property. The tool still updates the <JRE>/lib/zi
      area, but the runtime looks up the directory specified by the
      property.
    * The property value is evaluated only once when loading the
      sun.util.calendar.ZoneInfoFile class. This way, we can avoid
      mixing different versions of tzdata files at runtime.
    * "sun.zoneinfo.dir" lookup is under the do-privileged block.

I've tested builds, runtime lookup, and tzupdater. Also I tested the 
runtime with some broken tzdata files. There's one problem that the 
lookup code doesn't detect infinite recursions, which problem I need to 
fix later.

Could you please review the attached diffs? If those changes are OK, I 
will proceed with some paper work to get interface change (i.e., new 
property support) approval.

Best regards,
--
Masayoshi Okutsu


On 1/19/2008 5:03 AM, Keith Seitz wrote:
> Masayoshi Okutsu wrote:
>> Therefore, the proposed property needs to be supported for those who 
>> want to use another mechanism to update tzdata files.
>
> I don't believe that my proposed change in any way conflicts with the
> status quo. If the property is defined, tzdata is read from the value of
> the property. If the directory is not valid (or ZoneInfoMapping doesn't
> exist) or if the property is otherwise undefined or invalid, it is
> simply ignored, and the JDK-supplied tzdata is used instead. [Although 
> I admit, allowing this property to change makes me nervous. I would 
> rather it ALWAYS use the system data or NEVER use it -- rather like 
> how OpenJDK behaves today.]
>
>> I need to get approval on the proposed property support because it 
>> exposes an interface (even it's internal). To do that, I need to make 
>> a decision on the default value.
>
> Default, platform-specific values, no?
>
>> I've been having some difficulty to think of default locations for 
>> other platforms, especially Windows.
>
> I don't think Microsoft would ever release tzdata for use by Sun's 
> JRE, but I could just be pessimistic. O:-) The only hosts that this 
> really affects are Solaris and Linux.
>
>> So I  wondered if it's OK to make the property value undefined by
>> default. Would that be acceptable for you?
>
> While our (Red Hat) hands are tied, of course, I would not agree with 
> the decision to turn this off by default, effectively ignoring the 
> problem that the patch is attempting to address.
>
> Is there really no solution to this problem?
>
> Keith


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sun_zoneinfo_dir.diff
Url: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20080310/4f2199fb/attachment.ksh