TimeZone Updater Tool/Project, where would we put it? (original) (raw)

Andrew Leonard andrew_m_leonard at uk.ibm.com
Thu Nov 28 15:48:20 UTC 2019

Thanks for all the input. So i'm going to set the "scene" on what we currently have and how it currently works, and a possible proposal:

Background: Code is loosely based off of our bespoke IBM JDK 6/7/8 TimeZone Updater, but has been updated and extended to support OpenJDK8+ JDKs.

Current Architecture:

  1. A Build by a Vendor|OpenJDK is done to produce a "jtzuYYYY[a-z].zip" that contains the latest IANA data built into a "rearguard" "tzdb.dat" along with the tzupdater client tool.
  2. The "end user" who wants to patch their tzdb, simply downloads the "jtzuYYYY[a-z].zip" from the Vendor|OpenJDK unzips and runs the tool to patch their chosen JDKs...

Current features and limitations:

Possibilities: For (1) maybe we could:

Thoughts? 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: 26/11/2019 15:10 Subject: [EXTERNAL] Re: TimeZone Updater Tool/Project, where would we put it? Sent by: "jdk-dev" <jdk-dev-bounces at openjdk.java.net>

To take the discussion in a different direction, the original intention of JSR-310 was that time-zone updates should be delivered as modular jar files. Developers would just use their favorite tooling (maven/gradle etc) to add the new tzdb jar file to the module path, and hey-presto the tzdb data would be updated.

Early versions of JSR-310 code had all of this working, although I'm not certain whether it still does. (JSR-310 was introduced before the module system, so there is likely to be some work needed). The versioning system does still exist though. ie. the JDK can have multiple versions of the tzdb loaded and pick the latest. See ZoneRulesProvider and TzdbZoneRulesProvider for the code that may or may not need tweaking (it uses ServiceLoader).

A tool that patches the JDK installation seems rather an old fashioned approach compared to a modular jar one. That said, there are issues around data other than the tzdb rules themselves, eg. the name of a zone, that might trip up a modular jar file approach.

Does anyone else think a modular jar file approach is worth pursuing instead?

Stephen

On Mon, 25 Nov 2019 at 10:03, Andrew Leonard <andrew_m_leonard at uk.ibm.com> wrote:

Hi there, Not had a lot of interest in contributing this yet, so was going to ask the question a different way. If we were to contribute it where would we put it? - As part of the JDK project? - Create its own project? and associated mercurial repo? - Add to an existing other tooling project? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrewmleonard at uk.ibm.com 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