RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb

roger riggs roger.riggs at oracle.com
Thu Jun 19 20:42:23 UTC 2014

Hi Sherman,

Looks ok.

Thanks, Roger

On 6/16/2014 1:00 PM, Xueming Shen wrote:
> 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
> builder.
> http://cr.openjdk.java.net/~sherman/8042369/webrev
> Thanks!
> -Sherman
> 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
>> Roger
>> On 5/19/2014 2:12 PM, Xueming Shen wrote:
>>> Hi,
>>> 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:-)
>>> http://cr.openjdk.java.net/~sherman/8042369/webrev
>>> -Sherman
>>> 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.
>>> http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev
>>> On 05/04/2014 11:16 PM, Xueming Shen wrote:
>>>> Hi
>>>> 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
>>>> Oracle.
>>>> Here is the webrev for the idea
>>>> http://cr.openjdk.java.net/~sherman/tzdbProvider/webrev/
>>>> 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)
>>>> Thanks!
>>>> -Sherman

More information about the core-libs-dev mailing list