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

[Ben Evans]

Hi Andrew,

This looks like a great tool and very useful.

At New Relic we have definitely seen customer cases where this would have
been helpful, as well as for our own use. We would love to see this
open-sourced, and agree that upstream would be ideal (if feasible) - if
not, then definitely consider AdoptOpenJDK instead.

If you haven't already done so, I'd suggest talking to Andrew Haley at Red
Hat (copied) - as those folks would be the arbiters for getting this into 8
& 11.

Please keep the list updated as to your progress, and New Relic would be
happy to help test this once it's at a suitable stage (I assume there's not
much engineering work required on the tool itself, just getting it merged
and packaged?).

Thanks,

Ben

On Thu, Nov 28, 2019 at 3:50 PM Andrew Leonard <andrew_m_leonard at uk.ibm.com>
wrote:

> 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:
> - The tool comes in two phases:
> 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:
> - Supports only "rearguard" format tzdb.dat, but this is then compatible
> with JDK8,11,13+
> - tzupdater tool searchs for JDKs based on a "signature" recognition
> (layout of files...), but it only has to recognize "is it JDK8", "is it
> JDK11+" ?
> - Various modes of operation to tzupdater client tool, for specifying
> specific JDK/JRE location(s), either via cmdline or using a GUI.
>
> Possibilities:
> For (1) maybe we could:
> - Contribute all the tzupdater code to the JDK (jdk/jdk) project under the
> folder "src/tzupdater"
> - Add configure option --build-latest-tzupdater
> - When specified it:
>     - upgrades the IANA files with the latest from IANA
>     - once tzdb.dat has been built as part of gendata target, the
> src/tzupdater is built which produces
> "build/<platformdir>/images/tzupdater/jtzuYYYY[a-z].zip"
> (2):
> - Currently the built "jtzuYYYY[a-z]/zip" can be applied by the end user
> to any jdk8+ based on current features and "rearguard" compatibility.
>
> 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: andrew_m_leonard 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
>
>