RFR: JDK-8042369 Remove duplicated java.time classes in build.tools.tzdb
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
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
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
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
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
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
participants (2)
-
roger riggs
-
Xueming Shen