RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb
xueming.shen at oracle.com
Mon Jun 16 17:00:37 UTC 2014
OK, let's go the non-controversial approach. The webrev has been updated to simply remove
those redundant/duplicated class files from the builder and use the updated version of the tzdb
On 5/20/2014 1:52 PM, roger riggs wrote:
> Hi Sherman,
> Even though it has well defined content, checking in the tar.gz seems not quite right.
> Can the tests reconstruct the tar file from the contents or directly use
> the IANA data on demand from the IANA site?
> From a maintenance point of view, functions added to the JDK should be
> well used and maintained and be well supported.
> TzdbZoneRulesCompiler.java: +130 The error for srcFile == null still mentions "-srcdir".
> :+153; the commented out message should be removed
> On 5/19/2014 2:12 PM, Xueming Shen wrote:
>> I've not got any feedback so far, so I assume it's good:-)
>> Anyway, I'm going a little further to throw in a TarInputStream so now we just build the
>> tzdb data directly on the tzdata201xy.tar.gz from iana site. I'm not sure if it is OK to
>> check in the original .tar.gz file into the jdk repository though.
>> There are also more improvements in this version, it is much faster now. It might
>> not matter as it is only used during build time, though:-)
>> Btw, I'm still trying to sell the idea of checking in a second tzdb provider implementation
>> into the jdk, which directly loads in the tzdb data by using the iana original source data,
>> with the assumption that this might be useful at least in certain circumstance (such as
>> one gov pushes a tz change, and some of your big jdk customers need their apps run with
>> the new data in next 24 hrs...) in the future.
>> On 05/04/2014 11:16 PM, Xueming Shen wrote:
>>> Please help review the change for #8042369
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8042369
>>> Webrev: http://cr.openjdk.java.net/~sherman/8042369/webrev
>>> In jdk8 we had to duplicate dozen java.time classes in build.tools to build the timezone data
>>> for the new JSR310 timezone data compiler, which uses the new jdk8 java.time classes (these
>>> classes don't exit in the < 8 boot jdk). JDK9 has switched to use the jdk8 as the boot jdk, so
>>> most of these duplicated classes are no longer needed, with ZoneRules as the only exception.
>>> The ZoneRules is still needed to help the tzdb compiler to output the tzdb data in the
>>> serialization forms of those transitions and rules. The proposed change here is to remove
>>> those unneeded duplicated classes.
>>> I also took the opportunity to re-organize/re-wrote the "builder" classes to have a faster, simpler
>>> and and straightforward implementation, with the goal of migrating it into a second default
>>> ZoneRulesProvider later to plug it into jdk, so jdk/jre can uses the tzdb source data from the
>>> IANA directly. One of the benefits of such a provider is that the end user may just drop the latest
>>> timezone data file into the jdk/jre and go, without waiting for the latest timezone binary bits from
>>> Here is the webrev for the idea
>>> The only disadvantage appears to be the possible "slowdown" of startup time because of
>>> the reading and compiling of the 200k tzdb source data...(we need another new "bridge" for
>>> j.u.TimeZone, if we go with this direction)
More information about the core-libs-dev