From rachna.goel at oracle.com Mon Oct 3 07:22:07 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Mon, 3 Oct 2016 12:52:07 +0530 Subject: RFR:JDK-8166993: Typo in java.util.Locale Message-ID: <272969f3-29e8-814b-eb08-d003e694319a@oracle.com> Hi, Please review this simple documentation fix for JDK-8166993. Bug : https://bugs.openjdk.java.net/browse/JDK-8166993 webrev :http://cr.openjdk.java.net/~rgoel/JDK-8166993/webrev/ Thanks, Rachna From yuka.kamiya at oracle.com Mon Oct 3 09:49:31 2016 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Mon, 3 Oct 2016 18:49:31 +0900 Subject: RFR:JDK-8166993: Typo in java.util.Locale In-Reply-To: <272969f3-29e8-814b-eb08-d003e694319a@oracle.com> References: <272969f3-29e8-814b-eb08-d003e694319a@oracle.com> Message-ID: <231c7ca5-b0bc-173f-5e6c-e5057cec57ea@oracle.com> Hi Rachna, The fix looks good to me. Thanks, -- Yuka On 2016/10/03 16:22, Rachna Goel wrote: > Hi, > > Please review this simple documentation fix for JDK-8166993. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8166993 > > webrev :http://cr.openjdk.java.net/~rgoel/JDK-8166993/webrev/ > > Thanks, > > Rachna > From nishit.jain at oracle.com Mon Oct 3 10:56:04 2016 From: nishit.jain at oracle.com (Nishit Jain) Date: Mon, 3 Oct 2016 16:26:04 +0530 Subject: Review Request for JDK-8165466: DecimalFormat percentage format can contain unexpected % Message-ID: Hi, Please review the fix for JDK-8165466 Bug: https://bugs.openjdk.java.net/browse/JDK-8165466 Webrev: http://cr.openjdk.java.net/~nishjain/8165466/webrev.04/ Fix: FastPathData was not reinitialized for the subsequent format calls, hence FastPathData.fastPathContainer was using the old char array buffer to handle the format calls. Changes are made to reset the FastPathData in each subsequent format calls. Regards, Nishit Jain From ramanand.patil at oracle.com Mon Oct 3 12:27:23 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 3 Oct 2016 05:27:23 -0700 (PDT) Subject: RFR: 8166875: (tz) Support tzdata2016g Message-ID: <44b5d97a-222a-4d46-8896-8a2115108081@default> HI all, Please review the latest TZDATA integration (tzdata2016g) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8166875 Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.00/ All the TimeZone related tests are passed after integration. [BugID is updated for tests TimeZoneTest.java and Bug8134384.java, since they verify the renamed TZID "Asia/Yangon"]. Regards, Ramanand. From yuka.kamiya at oracle.com Mon Oct 3 13:52:11 2016 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Mon, 3 Oct 2016 22:52:11 +0900 Subject: Review Request for JDK-8165466: DecimalFormat percentage format can contain unexpected % In-Reply-To: References: Message-ID: <5a5d17de-fc5e-874f-b71f-d1e612909c61@oracle.com> Hi Nisht, The fix looks good to me. Thanks, -- Yuka On 2016/10/03 19:56, Nishit Jain wrote: > Hi, > > Please review the fix for JDK-8165466 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165466 > Webrev: http://cr.openjdk.java.net/~nishjain/8165466/webrev.04/ > > > Fix: FastPathData was not reinitialized for the subsequent format > calls, hence FastPathData.fastPathContainer was using the old char > array buffer to handle the format calls. Changes are made to reset the > FastPathData in each subsequent format calls. > > Regards, > Nishit Jain From martinrb at google.com Mon Oct 3 15:24:40 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 Oct 2016 08:24:40 -0700 Subject: RFR: 8166875: (tz) Support tzdata2016g In-Reply-To: <44b5d97a-222a-4d46-8896-8a2115108081@default> References: <44b5d97a-222a-4d46-8896-8a2115108081@default> Message-ID: Hi Ramanand, Pleased to meet you! I expected to see Yangon added to ZoneName, because of the existing reference to Rangoon java/time/test/java/time/format/ZoneName.java:179: "Asia/Rangoon", "Myanmar", "Asia/Rangoon", Is ZoneName.java trying to maintain a comprehensive list of zone names? """Yangon (???????) is a combination of the two words yan (???) and koun (????), which mean "enemies" and "run out of", respectively. It is also translated as "End of Strife".""" On Mon, Oct 3, 2016 at 5:27 AM, Ramanand Patil wrote: > HI all, > Please review the latest TZDATA integration (tzdata2016g) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8166875 > Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.00/ > > All the TimeZone related tests are passed after integration. > [BugID is updated for tests TimeZoneTest.java and Bug8134384.java, since > they verify the renamed TZID "Asia/Yangon"]. > > Regards, > Ramanand. > From martinrb at google.com Mon Oct 3 15:33:36 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 Oct 2016 08:33:36 -0700 Subject: RFR:JDK-8166993: Typo in java.util.Locale In-Reply-To: <272969f3-29e8-814b-eb08-d003e694319a@oracle.com> References: <272969f3-29e8-814b-eb08-d003e694319a@oracle.com> Message-ID: Thanks! On Mon, Oct 3, 2016 at 12:22 AM, Rachna Goel wrote: > Hi, > > Please review this simple documentation fix for JDK-8166993. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8166993 > > webrev :http://cr.openjdk.java.net/~rgoel/JDK-8166993/webrev/ > > Thanks, > > Rachna > > From rachna.goel at oracle.com Mon Oct 3 15:33:44 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Mon, 3 Oct 2016 21:03:44 +0530 Subject: RFR:JDK-8146750:java.time.Month.getDisplayName() return incorrect narrow names with JRE provider. In-Reply-To: <5b85d463-8627-6a33-862b-4f2b5036c091@oracle.com> References: <5b85d463-8627-6a33-862b-4f2b5036c091@oracle.com> Message-ID: <1ae4b042-a162-21a7-2eef-618c76704cce@oracle.com> Hi Masayoshi, Thanks for pointing out that. I have changed this test for java.time. Please have a look at updated webrev : http://cr.openjdk.java.net/~rgoel/JDK-8146750/webrev.04/ Thanks, Rachna On 9/29/16 7:31 PM, Masayoshi Okutsu wrote: > Hi Rachna, > > Sorry, but I've somehow overlooked this fix as java.time changes. The > test needs to be written for java.time. > > Thanks, > Masayoshi > > > On 9/28/2016 5:13 PM, Rachna Goel wrote: >> Hi, >> >> Please review fix for JDK-8146750. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8146750 >> >> webrev : http://cr.openjdk.java.net/~rgoel/JDK-8146750/webrev.03/ >> >> Fix is to retrieve Narrow and Narrow_Standalone Month names as well >> as Day names one by one, as they can be duplicate. >> >> Thanks, >> >> Rachna >> > From masayoshi.okutsu at oracle.com Tue Oct 4 07:49:10 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 4 Oct 2016 16:49:10 +0900 Subject: Review Request for JDK-8165466: DecimalFormat percentage format can contain unexpected % In-Reply-To: <5a5d17de-fc5e-874f-b71f-d1e612909c61@oracle.com> References: <5a5d17de-fc5e-874f-b71f-d1e612909c61@oracle.com> Message-ID: +1 Masayoshi On 10/3/2016 10:52 PM, Yuka Kamiya wrote: > Hi Nisht, > > The fix looks good to me. > > Thanks, > -- > Yuka > > > On 2016/10/03 19:56, Nishit Jain wrote: >> Hi, >> >> Please review the fix for JDK-8165466 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8165466 >> Webrev: http://cr.openjdk.java.net/~nishjain/8165466/webrev.04/ >> >> >> Fix: FastPathData was not reinitialized for the subsequent format >> calls, hence FastPathData.fastPathContainer was using the old char >> array buffer to handle the format calls. Changes are made to reset >> the FastPathData in each subsequent format calls. >> >> Regards, >> Nishit Jain > From masayoshi.okutsu at oracle.com Tue Oct 4 07:49:31 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 4 Oct 2016 16:49:31 +0900 Subject: RFR:JDK-8166993: Typo in java.util.Locale In-Reply-To: <231c7ca5-b0bc-173f-5e6c-e5057cec57ea@oracle.com> References: <272969f3-29e8-814b-eb08-d003e694319a@oracle.com> <231c7ca5-b0bc-173f-5e6c-e5057cec57ea@oracle.com> Message-ID: +1 Masayoshi On 10/3/2016 6:49 PM, Yuka Kamiya wrote: > Hi Rachna, > > The fix looks good to me. > > Thanks, > -- > Yuka > > On 2016/10/03 16:22, Rachna Goel wrote: >> Hi, >> >> Please review this simple documentation fix for JDK-8166993. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8166993 >> >> webrev :http://cr.openjdk.java.net/~rgoel/JDK-8166993/webrev/ >> >> Thanks, >> >> Rachna >> > From ramanand.patil at oracle.com Tue Oct 4 10:22:18 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Tue, 4 Oct 2016 03:22:18 -0700 (PDT) Subject: RFR: 8166875: (tz) Support tzdata2016g In-Reply-To: References: <44b5d97a-222a-4d46-8896-8a2115108081@default> Message-ID: <68b8173e-5fca-42f0-bc0e-d0066acd76bb@default> Hi Martin, Thank you for your review and explanation of "Yangon". I liked the translation "End of Strife". Looking at the description of the ZoneNames.java: * The zid<->metazone mappings are based on CLDR metaZones.xml. * The alias mappings are based on Link entries in tzdb data files. I had thought to not update this file because the CLDR metaZones.xml file doesn?t have this entry updated. But I think you are correct, since Link entry has this alias mentioned, there is no harm in adding these entries to zidMap and aliasMap arrays. Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.01/ Changes done: - Updated src/java.base/share/classes/java/time/format/ZoneName.java to include "Yangon" entry. - Removed unused imports from src/java.base/share/classes/java/time/format/ZoneName.java - Updated ZoneName.java in the test package as well to include "Yangon". [test/java/time/test/java/time/format/ZoneName.java] - Updated the bugID for test/java/time/test/java/time/format/TestZoneTextPrinterParser.java since this uses the "ZoneName.java" defined in test package. Also, looks like ZoneName.java is trying to maintain a comprehensive list of zone names. Though I found very few zone names are missing from this file like: "Europe/Busingen", "America/Fort_Nelson", "Antarctica/Troll" etc... Regards, Ramanand. From: Martin Buchholz [mailto:martinrb at google.com] Sent: Monday, October 03, 2016 8:55 PM To: Ramanand Patil Cc: i18n-dev at openjdk.java.net; core-libs-dev Subject: Re: RFR: 8166875: (tz) Support tzdata2016g Hi Ramanand, Pleased to meet you! I expected to see Yangon added to?ZoneName, because of the existing reference to Rangoon java/time/test/java/time/format/ZoneName.java:179: ? ? ? ?"Asia/Rangoon", "Myanmar", "Asia/Rangoon", Is ZoneName.java trying to maintain a comprehensive list of zone names? """Yangon (???????) is a combination of the two words yan (???) and koun (????), which mean "enemies" and "run out of", respectively. It is also translated as "End of Strife".""" On Mon, Oct 3, 2016 at 5:27 AM, Ramanand Patil wrote: HI all, Please review the latest TZDATA integration (tzdata2016g) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8166875 Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.00/ All the TimeZone related tests are passed after integration. [BugID is updated for tests TimeZoneTest.java and Bug8134384.java, since they verify the renamed TZID "Asia/Yangon"]. Regards, Ramanand. From martinrb at google.com Tue Oct 4 21:27:55 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 4 Oct 2016 14:27:55 -0700 Subject: RFR: 8166875: (tz) Support tzdata2016g In-Reply-To: <68b8173e-5fca-42f0-bc0e-d0066acd76bb@default> References: <44b5d97a-222a-4d46-8896-8a2115108081@default> <68b8173e-5fca-42f0-bc0e-d0066acd76bb@default> Message-ID: Looks good to me! On Tue, Oct 4, 2016 at 3:22 AM, Ramanand Patil wrote: > Hi Martin, > Thank you for your review and explanation of "Yangon". I liked the > translation "End of Strife". > > Looking at the description of the ZoneNames.java: > * The zid<->metazone mappings are based on CLDR metaZones.xml. > * The alias mappings are based on Link entries in tzdb data files. > > I had thought to not update this file because the CLDR metaZones.xml file > doesn?t have this entry updated. > But I think you are correct, since Link entry has this alias mentioned, > there is no harm in adding these entries to zidMap and aliasMap arrays. > Here is the updated Webrev: http://cr.openjdk.java.net/~ > rpatil/8166875/webrev.01/ > > Changes done: > - Updated src/java.base/share/classes/java/time/format/ZoneName.java > to include "Yangon" entry. > - Removed unused imports from src/java.base/share/classes/ > java/time/format/ZoneName.java > - Updated ZoneName.java in the test package as well to include > "Yangon". [test/java/time/test/java/time/format/ZoneName.java] > - Updated the bugID for test/java/time/test/java/time/format/TestZoneTextPrinterParser.java > since this uses the "ZoneName.java" defined in test package. > > Also, looks like ZoneName.java is trying to maintain a comprehensive list > of zone names. Though I found very few zone names are missing from this > file like: "Europe/Busingen", "America/Fort_Nelson", "Antarctica/Troll" > etc... > > > Regards, > Ramanand. > > From: Martin Buchholz [mailto:martinrb at google.com] > Sent: Monday, October 03, 2016 8:55 PM > To: Ramanand Patil > Cc: i18n-dev at openjdk.java.net; core-libs-dev net> > Subject: Re: RFR: 8166875: (tz) Support tzdata2016g > > Hi Ramanand, > Pleased to meet you! > > I expected to see Yangon added to ZoneName, because of the existing > reference to Rangoon > > java/time/test/java/time/format/ZoneName.java:179: "Asia/Rangoon", > "Myanmar", "Asia/Rangoon", > > Is ZoneName.java trying to maintain a comprehensive list of zone names? > > """Yangon (???????) is a combination of the two words yan (???) and koun > (????), which mean "enemies" and "run out of", respectively. It is also > translated as "End of Strife".""" > > > On Mon, Oct 3, 2016 at 5:27 AM, Ramanand Patil ramanand.patil at oracle.com> wrote: > HI all, > Please review the latest TZDATA integration (tzdata2016g) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8166875 > Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.00/ > > All the TimeZone related tests are passed after integration. > [BugID is updated for tests TimeZoneTest.java and Bug8134384.java, since > they verify the renamed TZID "Asia/Yangon"]. > > Regards, > Ramanand. > From masayoshi.okutsu at oracle.com Wed Oct 5 03:18:50 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 5 Oct 2016 12:18:50 +0900 Subject: RFR: 8166875: (tz) Support tzdata2016g In-Reply-To: <68b8173e-5fca-42f0-bc0e-d0066acd76bb@default> References: <44b5d97a-222a-4d46-8896-8a2115108081@default> <68b8173e-5fca-42f0-bc0e-d0066acd76bb@default> Message-ID: Hi Ramanand, I don't think it's appropriate to add the bug ID to test/sun/util/resources/cldr/Bug8134384.java. This test doesn't verify the TimeZoneNames*.java changes of this fix. Otherwise, the change looks OK to me. Thanks, Masayoshi On 10/4/2016 7:22 PM, Ramanand Patil wrote: > Hi Martin, > Thank you for your review and explanation of "Yangon". I liked the translation "End of Strife". > > Looking at the description of the ZoneNames.java: > * The zid<->metazone mappings are based on CLDR metaZones.xml. > * The alias mappings are based on Link entries in tzdb data files. > > I had thought to not update this file because the CLDR metaZones.xml file doesn?t have this entry updated. > But I think you are correct, since Link entry has this alias mentioned, there is no harm in adding these entries to zidMap and aliasMap arrays. > Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.01/ > > Changes done: > - Updated src/java.base/share/classes/java/time/format/ZoneName.java to include "Yangon" entry. > - Removed unused imports from src/java.base/share/classes/java/time/format/ZoneName.java > - Updated ZoneName.java in the test package as well to include "Yangon". [test/java/time/test/java/time/format/ZoneName.java] > - Updated the bugID for test/java/time/test/java/time/format/TestZoneTextPrinterParser.java since this uses the "ZoneName.java" defined in test package. > > Also, looks like ZoneName.java is trying to maintain a comprehensive list of zone names. Though I found very few zone names are missing from this file like: "Europe/Busingen", "America/Fort_Nelson", "Antarctica/Troll" etc... > > > Regards, > Ramanand. > > From: Martin Buchholz [mailto:martinrb at google.com] > Sent: Monday, October 03, 2016 8:55 PM > To: Ramanand Patil > Cc: i18n-dev at openjdk.java.net; core-libs-dev > Subject: Re: RFR: 8166875: (tz) Support tzdata2016g > > Hi Ramanand, > Pleased to meet you! > > I expected to see Yangon added to ZoneName, because of the existing reference to Rangoon > > java/time/test/java/time/format/ZoneName.java:179: "Asia/Rangoon", "Myanmar", "Asia/Rangoon", > > Is ZoneName.java trying to maintain a comprehensive list of zone names? > > """Yangon (???????) is a combination of the two words yan (???) and koun (????), which mean "enemies" and "run out of", respectively. It is also translated as "End of Strife".""" > > > On Mon, Oct 3, 2016 at 5:27 AM, Ramanand Patil wrote: > HI all, > Please review the latest TZDATA integration (tzdata2016g) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8166875 > Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.00/ > > All the TimeZone related tests are passed after integration. > [BugID is updated for tests TimeZoneTest.java and Bug8134384.java, since they verify the renamed TZID "Asia/Yangon"]. > > Regards, > Ramanand. From ramanand.patil at oracle.com Wed Oct 5 07:33:08 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Wed, 5 Oct 2016 00:33:08 -0700 (PDT) Subject: RFR: 8166875: (tz) Support tzdata2016g In-Reply-To: References: <44b5d97a-222a-4d46-8896-8a2115108081@default> <68b8173e-5fca-42f0-bc0e-d0066acd76bb@default> Message-ID: <48e1f954-204e-4a7a-a163-7fee6ea08f86@default> Hi Masayoshi, Thank you for pointing that small miss. During testing phase, I had actually renamed "Asia/Rangoon" to "Asia/Yangon" (Asia/Rangoon entry was deleted) in TimeZoneNames*.java and this test case was failing along with other test cases, hence the bug ID tag was added there. But after correcting the TimeZoneNames*.java with correct changes I forgot to remove the bug ID from this bug. Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.02/ Regards, Ramanand. -----Original Message----- From: Masayoshi Okutsu Sent: Wednesday, October 05, 2016 8:49 AM To: Ramanand Patil ; Martin Buchholz Cc: core-libs-dev ; i18n-dev at openjdk.java.net Subject: Re: RFR: 8166875: (tz) Support tzdata2016g Hi Ramanand, I don't think it's appropriate to add the bug ID to test/sun/util/resources/cldr/Bug8134384.java. This test doesn't verify the TimeZoneNames*.java changes of this fix. Otherwise, the change looks OK to me. Thanks, Masayoshi On 10/4/2016 7:22 PM, Ramanand Patil wrote: > Hi Martin, > Thank you for your review and explanation of "Yangon". I liked the translation "End of Strife". > > Looking at the description of the ZoneNames.java: > * The zid<->metazone mappings are based on CLDR metaZones.xml. > * The alias mappings are based on Link entries in tzdb data files. > > I had thought to not update this file because the CLDR metaZones.xml file doesn?t have this entry updated. > But I think you are correct, since Link entry has this alias mentioned, there is no harm in adding these entries to zidMap and aliasMap arrays. > Here is the updated Webrev: > http://cr.openjdk.java.net/~rpatil/8166875/webrev.01/ > > Changes done: > - Updated src/java.base/share/classes/java/time/format/ZoneName.java to include "Yangon" entry. > - Removed unused imports from src/java.base/share/classes/java/time/format/ZoneName.java > - Updated ZoneName.java in the test package as well to include "Yangon". [test/java/time/test/java/time/format/ZoneName.java] > - Updated the bugID for test/java/time/test/java/time/format/TestZoneTextPrinterParser.java since this uses the "ZoneName.java" defined in test package. > > Also, looks like ZoneName.java is trying to maintain a comprehensive list of zone names. Though I found very few zone names are missing from this file like: "Europe/Busingen", "America/Fort_Nelson", "Antarctica/Troll" etc... > > > Regards, > Ramanand. > > From: Martin Buchholz [mailto:martinrb at google.com] > Sent: Monday, October 03, 2016 8:55 PM > To: Ramanand Patil > Cc: i18n-dev at openjdk.java.net; core-libs-dev > > Subject: Re: RFR: 8166875: (tz) Support tzdata2016g > > Hi Ramanand, > Pleased to meet you! > > I expected to see Yangon added to ZoneName, because of the existing > reference to Rangoon > > java/time/test/java/time/format/ZoneName.java:179: "Asia/Rangoon", "Myanmar", "Asia/Rangoon", > > Is ZoneName.java trying to maintain a comprehensive list of zone names? > > """Yangon (???????) is a combination of the two words yan (???) and koun (????), which mean "enemies" and "run out of", respectively. It is also translated as "End of Strife".""" > > > On Mon, Oct 3, 2016 at 5:27 AM, Ramanand Patil wrote: > HI all, > Please review the latest TZDATA integration (tzdata2016g) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8166875 > Webrev: http://cr.openjdk.java.net/~rpatil/8166875/webrev.00/ > > All the TimeZone related tests are passed after integration. > [BugID is updated for tests TimeZoneTest.java and Bug8134384.java, since they verify the renamed TZID "Asia/Yangon"]. > > Regards, > Ramanand. From rachna.goel at oracle.com Fri Oct 14 09:46:27 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Fri, 14 Oct 2016 15:16:27 +0530 Subject: RFR: JDK-8167992 : Update documentation of java.util.Date class Message-ID: <9ebb899f-ff05-e2b2-ddc4-d1666e34b80a@oracle.com> Hi, Please review a simple documentation fix for java.util.Date class. Bug : https://bugs.openjdk.java.net/browse/JDK-8167992 webrev : http://cr.openjdk.java.net/~rgoel/JDK-8167992/webrev/ Fix : updated links pointing to old websites. Thanks, Rachna From masayoshi.okutsu at oracle.com Mon Oct 17 09:30:28 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 17 Oct 2016 18:30:28 +0900 Subject: RFR: JDK-8167992 : Update documentation of java.util.Date class In-Reply-To: <9ebb899f-ff05-e2b2-ddc4-d1666e34b80a@oracle.com> References: <9ebb899f-ff05-e2b2-ddc4-d1666e34b80a@oracle.com> Message-ID: Hi Rachna, Use of double quote is preferable for href. (i.e., ). Otherwise, the fix looks good to me. Thanks, Masayoshi On 10/14/2016 6:46 PM, Rachna Goel wrote: > Hi, > > Please review a simple documentation fix for java.util.Date class. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8167992 > > webrev : http://cr.openjdk.java.net/~rgoel/JDK-8167992/webrev/ > > Fix : updated links pointing to old websites. > > Thanks, > Rachna From rachna.goel at oracle.com Mon Oct 17 10:14:09 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Mon, 17 Oct 2016 15:44:09 +0530 Subject: RFR: JDK-8167992 : Update documentation of java.util.Date class In-Reply-To: References: <9ebb899f-ff05-e2b2-ddc4-d1666e34b80a@oracle.com> Message-ID: Hi Masayoshi, Thanks for the review. I have updated href to have double quotes. http://cr.openjdk.java.net/~rgoel/JDK-8167992/webrev.01/ Thanks, Rachna On 10/17/16 3:00 PM, Masayoshi Okutsu wrote: > Hi Rachna, > > Use of double quote is preferable for href. (i.e., href="http://...">). Otherwise, the fix looks good to me. > > Thanks, > Masayoshi > > > On 10/14/2016 6:46 PM, Rachna Goel wrote: >> Hi, >> >> Please review a simple documentation fix for java.util.Date class. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8167992 >> >> webrev : http://cr.openjdk.java.net/~rgoel/JDK-8167992/webrev/ >> >> Fix : updated links pointing to old websites. >> >> Thanks, >> Rachna > From yuka.kamiya at oracle.com Mon Oct 17 11:05:39 2016 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Mon, 17 Oct 2016 20:05:39 +0900 Subject: RFR: JDK-8167992 : Update documentation of java.util.Date class In-Reply-To: References: <9ebb899f-ff05-e2b2-ddc4-d1666e34b80a@oracle.com>

Message-ID: <341cd0ae-3b8e-e5fc-bbb0-522a9b44e0cf@oracle.com> Looks good to me. Thanks, -- Yuka On 2016/10/17 19:14, Rachna Goel wrote: > Hi Masayoshi, > > Thanks for the review. > > I have updated href to have double quotes. > > http://cr.openjdk.java.net/~rgoel/JDK-8167992/webrev.01/ > > Thanks, > Rachna > > On 10/17/16 3:00 PM, Masayoshi Okutsu wrote: >> Hi Rachna, >> >> Use of double quote is preferable for href. (i.e.,

> href="http://...">). Otherwise, the fix looks good to me. >> >> Thanks, >> Masayoshi >> >> >> On 10/14/2016 6:46 PM, Rachna Goel wrote: >>> Hi, >>> >>> Please review a simple documentation fix for java.util.Date class. >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8167992 >>> >>> webrev : http://cr.openjdk.java.net/~rgoel/JDK-8167992/webrev/ >>> >>> Fix : updated links pointing to old websites. >>> >>> Thanks, >>> Rachna >> > From masayoshi.okutsu at oracle.com Mon Oct 17 15:26:37 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 18 Oct 2016 00:26:37 +0900 Subject: RFR: JDK-8167992 : Update documentation of java.util.Date class In-Reply-To: <341cd0ae-3b8e-e5fc-bbb0-522a9b44e0cf@oracle.com> References: <9ebb899f-ff05-e2b2-ddc4-d1666e34b80a@oracle.com>

<341cd0ae-3b8e-e5fc-bbb0-522a9b44e0cf@oracle.com> Message-ID: <34f1d941-13e5-42bd-eeff-cd89cf6a7fe5@oracle.com> +1 Masayoshi On 10/17/2016 8:05 PM, Yuka Kamiya wrote: > Looks good to me. > > Thanks, > -- > Yuka > > On 2016/10/17 19:14, Rachna Goel wrote: >> Hi Masayoshi, >> >> Thanks for the review. >> >> I have updated href to have double quotes. >> >> http://cr.openjdk.java.net/~rgoel/JDK-8167992/webrev.01/ >> >> Thanks, >> Rachna >> >> On 10/17/16 3:00 PM, Masayoshi Okutsu wrote: >>> Hi Rachna, >>> >>> Use of double quote is preferable for href. (i.e.,

Message-ID: +1 Thanks, -- Yuka On 2016/10/22 9:00, Naoto Sato wrote: > Looks good. > > Naoto > > On 10/21/16 12:43 AM, Masayoshi Okutsu wrote: >> Hi, >> >> Please review the fix for JDK-8152926. This is a doc fix to clarify >> initialization of the encoding information with the >> java.util.PropertyResourceBundle.encoding property. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8152926 >> >> Webrev: >> http://cr.openjdk.java.net/~okutsu/9/8152926/webrev.00/ >> >> Thanks, >> Masayoshi From ramanand.patil at oracle.com Mon Oct 24 07:28:08 2016 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 24 Oct 2016 00:28:08 -0700 (PDT) Subject: RFR: 8168512: (tz) Support tzdata2016h Message-ID: Hi all, Please review the latest TZDATA integration (tzdata2016h) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8168512 Webrev: http://cr.openjdk.java.net/~rpatil/8168512/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand. From erik.joelsson at oracle.com Mon Oct 24 10:03:18 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Oct 2016 12:03:18 +0200 Subject: RFR: 8165804: Revisit the way of loading BreakIterator rules/dictionaries In-Reply-To: <63b57fcc-48a8-773d-4ccd-feb2e4e25e48@oracle.com> References: <63b57fcc-48a8-773d-4ccd-feb2e4e25e48@oracle.com> Message-ID: Build change looks good. /Erik On 2016-10-20 10:33, Masayoshi Okutsu wrote: > Hi, > > Please review the changes for JDK-8165804 which is a follow-up of > JDK-8076757. Some notes on the changes. > > - Removed INCLUDES := $(TEXT_PKG_LD) from > make/gendata/GendataBreakIterator.gmk in order to avoid compiling > non-BreakIterator*.java for the build tool with boot JDK. > > - Added sun.util.resources.BreakIteratorResourceBundle which handles > loading of rule data and dictionaries. BreadIteratorResources* are its > subclasses in the java.base and jdk.localedata modules. > > - In BreakIteratorResources*, regular ResourceBundle loading of > BreakIteratorInfo* is avoided because a BreakIteratorInfo can't have > its parent chain. For example, BreakIteratorInfo_th doesn't have the > value for key "CharacterData" and > BreakIteratorResources_th.handleGetObject() must return null for > "CharacterData" rather than loading rule data given by the parent > BreakIteratorInfo. > > - Moved RuleBasedBreakIterator, DictionaryBasedBreakIterator, and > BreakDictionary to sun.text. BreakIteratorProviderTest.java was > changed to deal with this refactoring. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8165804 > > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8165804/webrev.01 > > Thanks, > Masayoshi > From martinrb at google.com Mon Oct 24 14:14:38 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 24 Oct 2016 07:14:38 -0700 Subject: RFR: 8168512: (tz) Support tzdata2016h In-Reply-To: References: Message-ID: Looks good to me! On Mon, Oct 24, 2016 at 12:28 AM, Ramanand Patil wrote: > Hi all, > > Please review the latest TZDATA integration (tzdata2016h) to JDK9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168512 > > Webrev: http://cr.openjdk.java.net/~rpatil/8168512/webrev.00/ > > > > All the TimeZone related tests are passed after integration. > > > > Regards, > > Ramanand. > > > From masayoshi.okutsu at oracle.com Tue Oct 25 00:40:42 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 25 Oct 2016 09:40:42 +0900 Subject: RFR: 8168512: (tz) Support tzdata2016h In-Reply-To: References:

Message-ID: <8573b95b-d879-cdcb-1468-3bc4ec5ef3eb@oracle.com> +1 Masayoshi On 10/24/2016 11:14 PM, Martin Buchholz wrote: > Looks good to me! > > On Mon, Oct 24, 2016 at 12:28 AM, Ramanand Patil > wrote: > >> Hi all, >> >> Please review the latest TZDATA integration (tzdata2016h) to JDK9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8168512 >> >> Webrev: http://cr.openjdk.java.net/~rpatil/8168512/webrev.00/ >> >> >> >> All the TimeZone related tests are passed after integration. >> >> >> >> Regards, >> >> Ramanand. >> >> >>