TimeZone Updater Tool/Project, where would we put it?
andrew_m_leonard at uk.ibm.com
Mon Dec 2 21:11:40 UTC 2019
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.
Java Runtimes Development
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
> >> tzdb.dat.
> >> 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.
> > -Alan
> 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