TimeZone Updater Tool/Project, where would we put it?

Seán Coffey sean.coffey at oracle.com
Tue Dec 3 14:18:26 UTC 2019


Hi Andrew,

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.

Regards,
Sean.

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.
> Thanks
> Andrew
>
> 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 [1] 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.
>
> Stephen
>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ThreeTen_threetenbp_blob_master_src_main_java_org_threeten_bp_zone_TzdbZoneRulesProvider.java-23L158&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=9qQDqnSn7Ktdv8hydCo_Ax1DlUfEzXPHa5-LZ_rdwfo&s=x_imqjkXxxomzFanxuU_oU9QiiCZgai8U0EULWkAWIE&e=
>
>
>
> On Mon, 2 Dec 2019 at 14:35, Andrew Leonard <andrew_m_leonard at uk.ibm.com>
> wrote:
>> Hi Sean,
>> Yes, I can see where you're going, it does seem more structured to
> define
>> 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
> module,
>> and then allow a openjdk make target to build just that with the latest
>> IANA and produce a upgradeable module replacement image for it...?
>> Thanks
>> Andrew
>>
>> 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
> would
>> 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 [1]
>>
>> 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.
>>
>> [1]
>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8153044-3FfocusedCommentId-3D13970444-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-253Acomment-2Dtabpanel-23comment-2D13970444&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=kUG0ybdJrp9uFosvwuDyIBKhr1b4R9POoYCFA81bk4c&s=0NmENnWxOJT5e40_QBVQp6lXE5NMyIALdG0ZYSw2dFw&e=
>
>>
>> Regards,
>> Sean.
>>
>> 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
>>>> tzdb.dat.
>>>> The user then unzips this and runs the "program" in the desired
> "mode".
>>>> 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.
>>>
>>> -Alan
>>
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>



More information about the jdk-dev mailing list