<i18n dev> tzdata lookup path support
Masayoshi.Okutsu at Sun.COM
Mon Mar 10 01:18:24 PDT 2008
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
* 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
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.
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?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the i18n-dev