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

[roger riggs]

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
>>>>
>>>>
>>>
>>
>