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

[Xueming Shen]

Masayoshi, Roger,

OK, let's forget the fancy TarInputStream for now:-)

Here is the webrev that just updates the code to use existing java.time classes
for tzdb data building.

http://cr.openjdk.java.net/~sherman/8042369/webrev

The difference compared to the last version [1] is that it reads in individual files
from the file system, as the existing tool does.

Thanks!
-Sherman

[1] http://cr.openjdk.java.net/~sherman/8042369/webrev.01/

On 05/20/2014 01: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
>>>
>>>
>>
>