TimeZone Updater Tool/Project, where would we put it?
sean.coffey at oracle.com
Tue Dec 3 14:18:26 UTC 2019
Just to answer your earlier question, no - we haven't invested cycles in
developing a new tzupdater tool just yet. As per other comments on this
mail thread, it looks like a fair degree of work to get to a cleaner,
more well designed tzupdater.
On 02/12/19 21:11, Andrew Leonard wrote:
> Hi Stephen,
> Thanks for your detailed test and description, you've highlighted some
> good issues here, which I don't think we've fully thought about, so that's
> great to discuss. I'll have a ponder on it, and discuss with my colleague.
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
> From: Stephen Colebourne <scolebourne at joda.org>
> To: jdk-dev <jdk-dev at openjdk.java.net>
> Date: 02/12/2019 15:35
> Subject: [EXTERNAL] Re: TimeZone Updater Tool/Project, where would
> we put it?
> Sent by: "jdk-dev" <jdk-dev-bounces at openjdk.java.net>
> I've just tried adding a later tzdb file with the current setup.
> * It is possible to set -Djava.time.zone.DefaultZoneRulesProvider and
> replace the standard TZDB provider.
> * The replacement class cannot just be a clone of
> TzdbZoneRulesProvider because it needs access to a restricted
> deserialization API in java.time.zone.Ser. (The Java module system
> makes this hard to work around)
> * Because of the restricted deserialization API, I'd be concerned
> about startup time if construction had to go through the main public
> API of ZoneRules etc.
> * It is not possible to just add a second TZDB provider with a
> different version via the service loader. The current design is based
> on the idea that a provider owns all the zone identifiers it provides,
> and thus no other provider can supply the same zone identifiers.
> The original code  looked for all files named tzdb.dat on the
> classpath, which allowed multiple versions to be loaded just by adding
> to the classpath. This ability was lost during integration, so there
> is a need to change the JDK code to find a way to get a modular jar to
> work well. It will need a bit of design work I suspect.
> My desire is that updating tzdb should be as easy as updating any
> other maven artifact. One possible approach would be for the
> TzdbZoneRulesProvider to use a second service loader call to get the
> actual tzdb .dat files.
> On Mon, 2 Dec 2019 at 14:35, Andrew Leonard <andrew_m_leonard at uk.ibm.com>
>> Hi Sean,
>> Yes, I can see where you're going, it does seem more structured to
>> an upgradeable module method... has anyone had a go at producing a
>> build/make mechanism to build one of those from the latest IANA data?
>> Could we modularise the current TzdbZoneRuleProvider into it's own
>> and then allow a openjdk make target to build just that with the latest
>> IANA and produce a upgradeable module replacement image for it...?
>> Andrew Leonard
>> Java Runtimes Development
>> IBM Hursley
>> IBM United Kingdom Ltd
>> internet email: andrew_m_leonard at uk.ibm.com
>> From: "Seán Coffey" <sean.coffey at oracle.com>
>> To: Alan Bateman <Alan.Bateman at oracle.com>, Andrew Leonard
>> <andrew_m_leonard at uk.ibm.com>
>> Cc: jdk-dev <jdk-dev at openjdk.java.net>
>> Date: 02/12/2019 12:55
>> Subject: [EXTERNAL] Re: TimeZone Updater Tool/Project, where
>> we put it?
>> I think Alan and Stephen Colebourne's comment may be on the right track
>> for this proposal.
>> The current tzupdater process is due an upgrade in how it operates.
>> We've also considered open sourcing a similar version of our tzupdater
>> tool but felt that it needs to be modernized. We should move away from
>> updating specific internals (like the tzdb.dat file which is not part or
>> Java SE spec AFAIK). Similar concerns were made in 2016 when proposals
>> to control the location of tzdb.dat were raised 
>> Moving to a service provider and/or upgradeable module solution may be a
>> good approach. At the moment, JDK 8+ uses the
>> java.time.zone.ZoneRulesProvider class as the default service provider.
>> It can be substituted with use of the
>> `java.time.zone.DefaultZoneRulesProvider' system property.
>> On 02/12/19 09:23, Alan Bateman wrote:
>>> On 29/11/2019 15:08, Andrew Leonard wrote:
>>>> The .zip contains the tzupdater "program" along with the latest
>>>> The user then unzips this and runs the "program" in the desired
>>>> Currently, it distinguishes jdk8 from jdk11+ only, and the only
>>>> version update is that contained within the new tzdb.dat eg."2019c".
>>>> So you can run the tool in "discovery" mode which will simply print
>>>> out what tzdb version each JDK is at...
>>>> The basis of updating any jdk8,11,13,.. with the tzdb.dat is based
>>>> upon the fact that it's currently producing a "rearguard" tzdb.dat
>>>> which is compatible with all these versions... This would need
>>>> changing going forward when vanguard is used, and perhaps with that
>>>> in sight it maybe best to update the tool to only patch the same
>>>> versions from which the updater was built from...
>>>> I can thus see several improvements being discussed here:
>>>> - Better JDK version detection
>>>> - Possibly provide release/version file update somewhere to identify
>>>> the update other than just in the tzdb.dat
>>>> - Make the tool "version" specific,ie. a jdk13 "updater.zip" will
>>>> only patch a jdk13 JDK.
>>> I assume "program" means something platform specific or maybe you mean
>>> a script?
>>> You haven't mentioned it yet but I assume it needs to update more than
>>> just tzdb. For JDK 9+ at least, it will need to update the TZ data in
>>> the packaged module (java.base.jmod) so that any replication with
>>> jlink will use the new TZ data too.
>>> There are lots of other questions but it might be better if you
>>> started a document to capture the needs, issues, and the possible
>>> technical approaches. That should help the discussion and help to see
>>> whether it make sense or not for something like this to be part of the
>>> JDK build or a separate patching tool.
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the jdk-dev