Re: [14] RFR: 8212970: TZ database in "vanguard" format support

2019-07-24 Thread Joe Wang

Thanks Naoto.  Looks good.

-Joe

On 7/24/19 3:24 PM, naoto.s...@oracle.com wrote:

Hi Joe,

Thank you for the review.

On 7/24/19 2:57 PM, Joe Wang wrote:

Hi Naoto,

The method findNegativeSavings method in TzdbZoneRulesProvider.java 
states that it "Find the minimum negative savings". While the result 
is correct since the rules all have the same value for SAVE, I wonder 
if that's ideal conceptually. Given a start LDT, shouldn't it be 
looking for the SAVE in the exact (narrower) date range (e.g. 1981 - 
1989 vs 1981 - max)?.


I believe it is working as such. The end year is retrieved within the 
method (line 879) and only the minimum negative saving values within 
the window is filtered.




NegativeDSTTest verifies the tzdata, that is the adjusted data after 
import, is that correct? I wonder a comment and a bit of details in 
the test summary would be helpful since there is no negative data in 
the test itself.


Good point. It is confusing. I supplied summary text in the test (also 
the similar line in TestZoneRules.java)


Here is the updated webrev:

http://cr.openjdk.java.net/~naoto/8212970/webrev.11/

Naoto


Best,
Joe

On 7/23/19 3:15 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix to the following enhancement:

https://bugs.openjdk.java.net/browse/JDK-8212970

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8212970/webrev.09/

This change aims to support the "vanguard" IANA time zone data 
format, which uses the negative savings and transition time beyond a 
day period. The change basically translates those negative savings 
and transition times, such as 25:00, into the ones that the current 
JDK recognizes, then produces the data file "tzdb.dat" at the build 
time. At the run time, the data file is read and interpreted as 
before. This way the produced tzdb.dat is compatible with the prior 
JDK releases so that the TZ Updater can also distribute it as a time 
zone update.


I have also refactored redundant copy of ZoneRules file in the build 
directory, by dynamically importing the file under src. Thus some 
build related files are modified. I am hoping folks on the build-dev 
can review those changes.


Naoto






Re: [14] RFR: 8212970: TZ database in "vanguard" format support

2019-07-24 Thread naoto . sato

Hi Joe,

Thank you for the review.

On 7/24/19 2:57 PM, Joe Wang wrote:

Hi Naoto,

The method findNegativeSavings method in TzdbZoneRulesProvider.java 
states that it "Find the minimum negative savings". While the result is 
correct since the rules all have the same value for SAVE, I wonder if 
that's ideal conceptually. Given a start LDT, shouldn't it be looking 
for the SAVE in the exact (narrower) date range (e.g. 1981 - 1989 vs 
1981 - max)?.


I believe it is working as such. The end year is retrieved within the 
method (line 879) and only the minimum negative saving values within the 
window is filtered.




NegativeDSTTest verifies the tzdata, that is the adjusted data after 
import, is that correct? I wonder a comment and a bit of details in the 
test summary would be helpful since there is no negative data in the 
test itself.


Good point. It is confusing. I supplied summary text in the test (also 
the similar line in TestZoneRules.java)


Here is the updated webrev:

http://cr.openjdk.java.net/~naoto/8212970/webrev.11/

Naoto


Best,
Joe

On 7/23/19 3:15 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix to the following enhancement:

https://bugs.openjdk.java.net/browse/JDK-8212970

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8212970/webrev.09/

This change aims to support the "vanguard" IANA time zone data format, 
which uses the negative savings and transition time beyond a day 
period. The change basically translates those negative savings and 
transition times, such as 25:00, into the ones that the current JDK 
recognizes, then produces the data file "tzdb.dat" at the build time. 
At the run time, the data file is read and interpreted as before. This 
way the produced tzdb.dat is compatible with the prior JDK releases so 
that the TZ Updater can also distribute it as a time zone update.


I have also refactored redundant copy of ZoneRules file in the build 
directory, by dynamically importing the file under src. Thus some 
build related files are modified. I am hoping folks on the build-dev 
can review those changes.


Naoto




Re: [14] RFR: 8212970: TZ database in "vanguard" format support

2019-07-24 Thread Joe Wang

Hi Naoto,

The method findNegativeSavings method in TzdbZoneRulesProvider.java 
states that it "Find the minimum negative savings". While the result is 
correct since the rules all have the same value for SAVE, I wonder if 
that's ideal conceptually. Given a start LDT, shouldn't it be looking 
for the SAVE in the exact (narrower) date range (e.g. 1981 - 1989 vs 
1981 - max)?.


NegativeDSTTest verifies the tzdata, that is the adjusted data after 
import, is that correct? I wonder a comment and a bit of details in the 
test summary would be helpful since there is no negative data in the 
test itself.


Best,
Joe

On 7/23/19 3:15 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix to the following enhancement:

https://bugs.openjdk.java.net/browse/JDK-8212970

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8212970/webrev.09/

This change aims to support the "vanguard" IANA time zone data format, 
which uses the negative savings and transition time beyond a day 
period. The change basically translates those negative savings and 
transition times, such as 25:00, into the ones that the current JDK 
recognizes, then produces the data file "tzdb.dat" at the build time. 
At the run time, the data file is read and interpreted as before. This 
way the produced tzdb.dat is compatible with the prior JDK releases so 
that the TZ Updater can also distribute it as a time zone update.


I have also refactored redundant copy of ZoneRules file in the build 
directory, by dynamically importing the file under src. Thus some 
build related files are modified. I am hoping folks on the build-dev 
can review those changes.


Naoto




Mac OS (Mojave / Xcode 10.3) build issue..

2019-07-24 Thread Sundararajan Athijegannathan

Hi,

After recent OS and Xcode upgrade (Mojave 10.14.6 and Xcode 10.3), I'm 
seeing JDK build failures on my machine. Bboth "jdk-dev" and 
"panama-dev" foreign branch. It is a fresh configure & clean build. "nm" 
is selected from /usr/local/bin/nm and that is from bintools 2.32 
(homebrew installed).


I thought it may be the latest Xcode. And so I downloaded Xcode 9.2 and 
installed it in a different location (/Applications/Xcode_9.2.app/). I 
then used configure 
--with-toolchain-path=/Applications/Xcode_9.2.app/Contents/Developer/usr/bin. 
But I got the same failure|

|
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/bytecodeHistogram.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/c1_CFGPrinter.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/c1_Defs.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/c1_InstructionPrinter.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/c1_ValueSet.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/cppInterpreter.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/cppInterpreterGenerator.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/decoder_elf.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/depChecker_x86.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/dtraceAttacher.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/elfFile.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/elfFuncDescTable.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/elfStringTable.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/elfSymbolTable.o: 
no symbols
/usr/local/bin/nm: 
$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/objs/instanceOop.o: 
no symbols
make[3]: *** 
[$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/symbols-objects] 
Error 1
make[3]: *** Deleting file 
`$panama-dev/build/macosx-x86_64-server-release/hotspot/variant-server/libjvm/symbols-objects'

make[3]: *** Waiting for unfinished jobs
make[2]: *** [hotspot-server-libs] Error 2

ERROR: Build failed for target 'images' in configuration 
'macosx-x86_64-server-release' (exit code 2)


No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See doc/building.html#troubleshooting for assistance.

make[1]: *** [main] Error 2
make: *** [images] Error 2

Thanks,
-Sundar