Re: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era

brev: http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.01/ While I was testing more, I realized the default implementation of Era.getDisplayName doesn't work with non-IsoChronology. I filed new bug report JDK-8171049. Thanks, Masayoshi On 12/8/2016 5:55 PM, Masayoshi Okutsu wrote: Hi, Please revi

RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era

Hi, Please review the fix for JDK-8054214. It was necessary to override Era::getDisplayName to get era names from the specified property. This one fixes getAbbreviation() as well. Issue: https://bugs.openjdk.java.net/browse/JDK-8054214 Webrev:

Re: RFR: JDK-8075577: java.time does not support HOST provider

Looks good to me. Masayoshi On 11/22/2016 6:30 PM, Rachna Goel wrote: Hi, Please review fix for JDK-8075577. Bug : https://bugs.openjdk.java.net/browse/JDK-8075577 webrev : http://cr.openjdk.java.net/~rgoel/JDK-8075577/webrev.01/ Fix is to introduce new private spi

Re: RFR: 8169191: (tz) Support tzdata2016j

Sorry, but I was confused with the wrong bug ID in Subject... Looks good to me. Masayoshi On 11/29/2016 4:28 AM, Martin Buchholz wrote: Thanks as always for keeping the tzdata pipeline moving! Looks good to me. On Mon, Nov 28, 2016 at 1:24 AM, Ramanand Patil

Re: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module

+1 Masayoshi On 11/15/2016 1:07 AM, Naoto Sato wrote: +1 Naoto On 11/13/16 11:12 PM, Rachna Goel wrote: Hi, Kindly review fix for JDK-8168906. https://bugs.openjdk.java.net/browse/JDK-8168906 Patch :http://cr.openjdk.java.net/~rgoel/JDK-8168906/webrev/ fix: As jdk.localedata module does

Re: RFR:JDK-8168906-Tighten permissions granted to the jdk.localedata module

test/sun/util/locale/provider/Bug8152817.java is a test with a SecurityManager. I18n SQE should have some. Masayoshi On 11/14/2016 11:59 PM, Sean Mullan wrote: Looks good. Are there any regression tests for this component that run with a SecurityManager? If not, it would be useful to add

Re: RFR: jdk8u-dev Backport of 8169191: (tz) Support tzdata2016i

+1 On 11/11/2016 1:48 AM, Martin Buchholz wrote: Looks good! On Thu, Nov 10, 2016 at 1:48 AM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA integration (tzdata2016i) to JDK8U. Since tzdata is cumulative, this bug fix backports both the tzdata

Re: RFR: 8169191: (tz) Support tzdata2016i

+1 On 11/8/2016 1:36 AM, Martin Buchholz wrote: Looks good to me! On Mon, Nov 7, 2016 at 2:43 AM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA integration (tzdata2016i) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8169191 Webrev:

Re: RFR: 8168512: (tz) Support tzdata2016h

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

Re: RFR: JDK-8146750:java.time.Month.getDisplayName() return incorrect narrow names with JRE provider on locale de,de_DE,en_US.

Looks good to me. Masayoshi On 10/20/2016 5:27 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.09/ Fix is to retrieve Narrow and Narrow_Standalone Month names

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

Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

Looks good to me. Thank you for fixing this bug! Masayoshi On 9/13/2016 11:49 PM, Thomas Stüfe wrote: Hi Christoph, thanks for your review! Yes, I can remove the blank. Kind Regards, Thomas On Tue, Sep 13, 2016 at 2:35 PM, Langer, Christoph

Re: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base

of the value being the file name w/o path. So I ended up with the fix. Naoto On 9/8/16 5:46 AM, Alan Bateman wrote: On 08/09/2016 03:51, Masayoshi Okutsu wrote: I thought Mandy suggested that the dictionary names in a ResourceBundle contain path names rather than base names, something like

Re: JDK 9 RFR of problem listing of IncludeLocalesPluginTest.java

On 6/2/2016 3:31 PM, Alan Bateman wrote: It's possible that the CLDR update added more languages and pushed this test over the edge. Excluding it temporarily should be fine while it is tracked down. The test doesn't detect any failures caused by the additional locales, which may or may not

Re: RFR: 8151876: (tz) Support tzdata2016d

ta Time" Regards, Sean. On 27/05/16 15:24, Masayoshi Okutsu wrote: This change seems to beyond my proposal that the "GMT±hh:mm" format is used for *new* zones with the "±hh" format. But this change removes *existing* zones which have cha

Re: RFR: 8151876: (tz) Support tzdata2016d

. e.g. "Asia/Almaty" instead of "Alma-Ata Time" Regards, Sean. On 27/05/16 15:24, Masayoshi Okutsu wrote: This change seems to beyond my proposal that the "GMT±hh:mm" format is used for *new* zones with the "±hh" format. But this change removes *existing*

Re: RFR: 8151876: (tz) Support tzdata2016d

This change seems to beyond my proposal that the "GMT±hh:mm" format is used for *new* zones with the "±hh" format. But this change removes *existing* zones which have changed to use the "±hh" format in tzdata. Can this cause any compatibility issues? And have we agreed to use the "GMT±hh:mm"

Re: RFR: 8151876: (tz) Support tzdata2016c

Looks good to me. But I'd like someone from java.time to review the changes to see if it's OK for java.time. Masayoshi On 4/4/2016 6:50 PM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA (tzdata2016c) integration to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Re: RFR: 8151876: (tz) Support tzdata2016b

"Astrakhan Time", "ASTT"}}, +{"Europe/Ulyanovsk", new String[] {"Ulyanovsk Time", "ULT", + "Ulyanovsk Summer Time", "ULST", +

Re: RFR: 8151876: (tz) Support tzdata2016b

Sorry for this belated response. I prefer to follow the tzdata abbreviations, like "+04". But that would require some major changes. An option would be not to define time zone names for the new zones with the +hh format. Thanks, Masayoshi On 3/17/2016 4:38 AM, Ramanand Patil wrote: Hi all,

Re: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor

Looks good to me. Masayoshi On 2/24/2016 4:40 PM, Ramanand Patil wrote: Hi all, Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104 Bug Description: DateFormatSymbols caches its own instance and calls this.clone() in the constructor. Because of this, any subclass

Re: RFR: 8148446: (tz) Support tzdata2016a

Hi Ramanand, I noticed that the zones in Yakutsk Time [1] seem to have their own names, such as "Khandyga Time" for Asia/Khandyga, and you seem to follow that convention for Asia/Chita. That causes some mismatch between the long names and abbreviations. I dag out some past tzdata fixes to

Re: RFR: JDK-8147912: test "parseWithZoneWithoutOffset" of java/time/tck/java/time/format/TCKDTFParsedInstant.java fail on de_DE locale

Looks OK to me. But I'd like some java.time people to review this change to see if the intention of this test is to run only in English. Thanks, Masayoshi On 1/27/2016 1:51 PM, Ramanand Patil wrote: Hi all, Please help me in reviewing this test fix. Regards, Ramanand. From:

Re: RFR: JDK-8144988: Unexpected timezone returned after parsing a date

- From: Masayoshi Okutsu Sent: Friday, January 15, 2016 8:18 AM To: Ramanand Patil; i18n-...@openjdk.java.net Cc: core-libs-dev@openjdk.java.net Subject: Re: RFR: JDK-8144988: Unexpected timezone returned after parsing a date Hi Ramanand, test/java/text/Format/DateFormat/Bug8141243.java

Re: RFR: JDK-8144988: Unexpected timezone returned after parsing a date

Hi Ramanand, test/java/text/Format/DateFormat/Bug8141243.java: 28 * @run main Bug8141243 29 * @run main/othervm -Djava.locale.providers=COMPAT Bug8141243 "COMPAT" is a new name of "JRE" in JDK 9. It's not supported in 8u. I think COMPAT is slightly ignored and that it becomes the same

Re: Code Review for JDK-8141243: Unexpected timezone returned after parsing a date

Hi Ramanand, I don't think this fix is correct. This change mixes up time zone IDs and display names. SimpleDateFomat should parse only display names. There's no perfect solution on the issue because the short display names (abbreviations) can't be unique. So, I'd suggest that the UTC

Re: [9] RFR: 8072600: Unicode 8 support

Looks good to me. Masayoshi On 10/16/2015 9:41 PM, Yuka Kamiya wrote: Hello, Please review a small change for 8072600: Unicode 8 support. Mainly date update from Unicode 7. JEP: http://openjdk.java.net/jeps/267 Issue: https://bugs.openjdk.java.net/browse/JDK-8072600 webrev:

Re: [9] RFR: 8133321: (tz) Support tzdata2015f

Looks good to me. Masayoshi On 8/13/2015 10:54 PM, Aleksej Efimov wrote: Hello, Please review latest tzdata (2015f) integration into JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015f/9/00 Testing shows no TZ related failures on all platforms. Thanks, Aleksej JBS:

Re: i18n dev RFR: 8032446: Support Unicode 7.0.0 in JDK 9

Looks OK to me too. Masayoshi On 7/15/2015 8:16 AM, Naoto Sato wrote: Looks good to me. Naoto On 7/13/15 1:20 AM, Yuka Kamiya wrote: Hello, Please review the fix for 8032446 to support Unicode 7 in JDK 9. https://bugs.openjdk.java.net/browse/JDK-8032446

Re: RFR: 8098547: (tz) Support tzdata2015e

+1 Masayoshi On 6/24/2015 9:58 PM, Seán Coffey wrote: Looks fine. Regards, Sean. On 24/06/15 12:05, Aleksej Efimov wrote: Hello, Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 Testing shows no TZ related failures on

Re: i18n dev RFR JDK-8042125: Japanese character converters incompatible between Java 7 and Java 8

Looks good to me. Masayoshi On 5/24/2015 9:26 AM, Xueming Shen wrote: Hi Please help the change for 8042125 issue: https://bugs.openjdk.java.net/browse/JDK-8042125 webrev: http://cr.openjdk.java.net/~sherman/8042125 It's a regression caused by the changes of JDK-6653797. The direct

Re: i18n dev RFR: 8077685: (tz) Support tzdata2015d

Looks good to me. Masayoshi On 4/29/2015 11:37 PM, Aleksej Efimov wrote: Hi, Please, review the fix for adding the latest tzdata2015d to JDK9. The JTREG and JPRT tests were executed. No failures were observed. Thank you, Aleksej [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8077685 [2]

Re: i18n dev RFR: 8075667: (tz) Support tzdata2015b

Looks good except that data changes keep requiring additional workaround to the run-time code. We do need a fix for JDK-8014468. Masayoshi On 3/27/2015 12:47 AM, Aleksej Efimov wrote: Hi, Please review the fix for adding the latest tzdata2015b to JDK9. The JTREG and JPRT tests were executed.

Re: i18n dev [9] RFR: 8072042: (tz) Support tzdata2015a

Looks good to me. Masayoshi On 2/4/2015 12:59 AM, Aleksej Efimov wrote: Hi, Could I have a review the latest tzdata2015a integration fix to JDK9, please. The regression tests run and JPRT testing (jdk_other,jdk_util, jdk_text, jdk_time test sets) shows no TZ related JDK9 failures. Thank

Re: RFR: 8065159: AttributedString has quadratic resize algorithm

Looks good to me. Masayoshi On 11/20/2014 11:20 AM, Naoto Sato wrote: OK, fine by me. Naoto On 11/19/14 4:37 PM, Martin Buchholz wrote: Thanks Naoto! Yeah, I noticed that too, but I'm not comfortable enough with this code to suggest a really good naming scheme. There are 3 levels of

Re: i18n dev RFR: 8064560: (tz) Support tzdata2014j

Looks good to me. Masayoshi On 11/17/2014 9:13 AM, Aleksej Efimov wrote: Hi, Please, review [1] tzdata2014j integration to JDK9 [2]. It is a straight-forward tzdata update, but new data caused a tzdb.dat build failure. It was reported under different bugId [3], there is a possible fix for

Re: RFR: 8059206: (tz) Support tzdata2014i

Hi Aleksej, src/java.base/share/classes/sun/util/resources/TimeZoneNames*.java: +{Pacific/Bougainville, new String[] {Bougainville Standard Time, BST, + Bougainville Summer Time, BST, +

Re: RFR: 8049343: (tz) Support tzdata2014g

/webrev.04 Thank you, Aleksej On 09/02/2014 10:03 AM, Masayoshi Okutsu wrote: Aleksej, I don't see the America/Grand_Turk change in webrev.04. I wonder if the webrev wasn't updated correctly. Thanks, Masayoshi On 9/1/2014 11:10 PM, Aleksej Efimov wrote: Masayoshi, I have addressed all your

Re: RFR: 8049343: (tz) Support tzdata2014g

/JDK-8057004 With Best Regards, Aleksej On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote: src/java.base/share/classes/sun/util/resources/TimeZoneNames.java: 239 String SLST[] = new String[] {Greenwich Mean Time, GMT, 240 Sierra Leone Summer Time

Re: RFR: 8049343: (tz) Support tzdata2014f

here: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02 Thanks, Aleksej On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote: We used to make name changes in the root (base) bundle as part of time zone data maintenance and deter only translations. But if you want to handle name changes later

Re: RFR: 8049343: (tz) Support tzdata2014f

/27/2014 12:34 PM, Masayoshi Okutsu wrote: Here are additional comments. src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java: I'm concerned about the workarounds. It's not new in this update, but this problem would make tzupdater data void until the workaround is added to the next

Re: RFR: 8049343: (tz) Support tzdata2014f

, Masayoshi Okutsu wrote: I think the long names of the Australia time zones should be revisited to be consistent with the abbreviation changes. The new abbreviations follow the S[tandard] and D[aylight saving] convention rather than the S[tandard] and S[ummer time] one. The long names

Re: RFR: 8049343: (tz) Support tzdata2014f

I think the long names of the Australia time zones should be revisited to be consistent with the abbreviation changes. The new abbreviations follow the S[tandard] and D[aylight saving] convention rather than the S[tandard] and S[ummer time] one. The long names, such as Eastern Summer Time

Re: RFR: 8042126: DateTimeFormatter MMMMM returns English value in Japanese locale

The root cause of this problem is the semantic difference between the legacy JRE resources and the CLDR-drived resources. The root CLDR resources have the narrow month names as numbers to be language-neutral, while the JRE root resources have them as English. If you specify Locale.ROOT, you

Re: RFR: 8042126: DateTimeFormatter MMMMM returns English value in Japanese locale

, Masayoshi Okutsu wrote: The root cause of this problem is the semantic difference between the legacy JRE resources and the CLDR-drived resources. The root CLDR resources have the narrow month names as numbers to be language-neutral, while the JRE root resources have them as English. If you

Re: RFR: 8044671: NPE from JapaneseEra when a new era is defined in calendar.properties

The copyright year range should be updated. Otherwise, the fix looks good to me. Masayoshi On 7/23/2014 11:51 PM, dmeetry degrave wrote: Hello, Please review a simple fix (jdk 8 and 9) for 8044671: NPE from JapaneseEra when a new era is defined in calendar.properties bug:

Re: i18n dev 8037343 Ready for review

Looks good to me. Thanks, Masayoshi On 5/15/2014 4:37 PM, Alan Bateman wrote: Forwarding to i18n-dev as that it usually the list where changes to the locale and resources are maintained. -Alan On 15/05/2014 04:45, Sandipan Razzaque wrote: Hi all, Please find below the webrev for bug

Re: i18n dev RFR: 8043012: (tz) Support tzdata2014c

Looks good to me. Masayoshi On 5/15/2014 7:59 AM, Aleksej Efimov wrote: Hello, Can I have a review for the tzdata2014c integration to JDK9. This is a standard release of tzdata (except the hurry with Egypt rules - the main part in this release). The following set of tests was executed with

Re: i18n dev Improve timezone mapping for AIX platform

, Volker On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu masayoshi.oku...@oracle.com mailto:masayoshi.oku...@oracle.com wrote: Hi Jonathan, The AIX specific code looks OK to me. But I'd suggest

Re: i18n dev RFR: 8038306: (tz) Support tzdata2014b

not used anywhere. Thanks, Aleksej On 04/03/2014 06:21 PM, Masayoshi Okutsu wrote: Hi Aleksej, Sorry, but I forgot about the generic names. Coordinated Universal Time and UTCshouldn't be the generic names. You will need to invent the names, something like Troll Time. Thanks, Masayoshi On 4/2

Re: i18n dev RFR: 8038306: (tz) Support tzdata2014b

Hi Aleksej, Sorry, but I forgot about the generic names. Coordinated Universal Time and UTCshouldn't be the generic names. You will need to invent the names, something like Troll Time. Thanks, Masayoshi On 4/2/2014 7:55 PM, Aleksej Efimov wrote: Hello, Can I have a review for the latest

Re: Improve timezone mapping for AIX platform

, Masayoshi Okutsu masayoshi.oku...@oracle.com wrote: Hi Jonathan, The AIX specific code looks OK to me. But I'd suggest the code be moved to getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also there's a function for producing a fallback ID in GMT±hh:mm, getGMTOffsetID() which can

Re: Improve timezone mapping for AIX platform

Hi Jonathan, The AIX specific code looks OK to me. But I'd suggest the code be moved to getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also there's a function for producing a fallback ID in GMT±hh:mm, getGMTOffsetID() which can be called in tzerr. Thanks, Masayoshi On

Re: i18n dev RFR: 8037012: (tz) Support tzdata2014a

+1 Masayoshi On 3/13/2014 9:18 PM, Seán Coffey wrote: Looks good to me. regards, Sean. On 12/03/2014 15:05, Aleksej Efimov wrote: Hello, Can I have a review for a tzdata2014a [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/8037012/9/webrev.00 The following test sets were

Re: i18n dev RFR: 8037180: [TEST_BUG] test/sun/util/calendar/zi/Zoneinfo.java incorrectly calculates raw GMT offset change time

+1 Masayoshi On 3/13/2014 9:19 PM, Seán Coffey wrote: Looks good Aleksej. A future rule change doesn't necessarily mean a new GMT offset change. Original test logic seemed buggy. regards, Sean. On 12/03/2014 15:06, Aleksej Efimov wrote: Hello, Can I have a review for a

Re: i18n dev RFR: 8030822: (tz) Support tzdata2013i

/TimeZoneNamesTest.java test and because of that this test was removed also. Thank you, Aleksej [1] http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.01/ http://cr.openjdk.java.net/%7Eaefimov/8030822/9/webrev.01/ On 01/23/2014 08:43 AM, Masayoshi Okutsu wrote: Hi Aleksej, I think this one is the first

Re: i18n dev RFR: 8030822: (tz) Support tzdata2013i

Hi Aleksej, I think this one is the first tzdata change for JDK9. So I'd suggest that all the TimeZoneNames*.properties files, which were temporarily created for the translation work, be removed. Thanks, Masayoshi On 1/21/2014 10:17 PM, Aleksej Efimov wrote: Hi, Can I have a review for

Re: i18n dev RFR: 8025051: Update resource files for TimeZone display names

translations in translation files. I suggest two approaches to resolve it: 1. Log different bug with all problems in translation files. 2. Wait for the next resource file translation update to address these problems. -Aleksej On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote: On 12/18/2013 6:43

Re: i18n dev RFR: 8025051: Update resource files for TimeZone display names

On 12/18/2013 6:43 PM, Aleksej Efimov wrote: Hi, Please help to review a fix [1] for 8025051 bug [2]. The following fix includes: Common to all modified files: - All year ranges in the copyright header should be modified accordingly. - The translation of time zone generic names were added

Re: i18n dev RFR: 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing

://bugs.openjdk.java.net/browse/JDK-8025051). For now, webrev [2] looks fine to take care of the short term regression failure. thanks, -michael On 13?10?22? 09:29 ??, Masayoshi Okutsu wrote: Hi Michael, 27 *@summary Test case for tzdata2005m support for 9 locales What's the purpose of this test

Re: i18n dev RFR: 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing

Hi Michael, 27 *@summary Test case for tzdata2005m support for 9 locales What's the purpose of this test? Do we really need to keep this one? Thanks, Masayoshi On 10/22/2013 8:13 PM, Aleksej Efimov wrote: Hi, Can I have a review for 8026772 [1] fix. The webrev link: [2] The timezone test

Re: i18n dev RFR: 8025255: (tz) Support tzdata2013g

On 13年10月10日 09:54 下午, Masayoshi Okutsu wrote: Hi Aleksej, Here are my review comments. - The copyright header of the data files shouldn't be removed. - TimeZoneNames.java: - Middle Europe Time, MET}}, + MET, MET}}, I don't think the long name should be changed. I didn't review the localized

Re: RFR: 8025255: (tz) Support tzdata2013g

Hi Aleksej, Here are my review comments. - The copyright header of the data files shouldn't be removed. - TimeZoneNames.java: - Middle Europe Time, MET}}, + MET, MET}}, I don't think the long name should be changed. I didn't

hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010

Changeset: 914c29c10bce Author:okutsu Date: 2013-10-02 15:31 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914c29c10bce 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 Reviewed-by: peytoia ! src/share/classes/java/util/GregorianCalendar.java

hg: jdk8/tl/jdk: 8022666: java.util.Calendar.set(int, int, int, int, int, int) documentation typo

Changeset: 82e3150778e0 Author:okutsu Date: 2013-10-02 17:57 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82e3150778e0 8022666: java.util.Calendar.set(int,int,int,int,int,int) documentation typo Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java

hg: jdk8/tl/jdk: 8024141: Unexpected timezone display name

Changeset: 13ee370ee8b3 Author:okutsu Date: 2013-09-11 15:29 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13ee370ee8b3 8024141: Unexpected timezone display name Reviewed-by: peytoia ! src/share/classes/sun/util/locale/provider/LocaleResources.java +

Re: i18n dev java.util.Locale changes

give more flexibility, but I'm not sure how much it would add value to the API use. You can implement your own Iterable, but would many developers implement an Iterable to give a language priority list? Masayoshi On 2013/08/29 5:42, Alan Bateman wrote: On 28/08/2013 14:25, Masayoshi Okutsu

Re: i18n dev java.util.Locale changes

(adding core-libs-dev) Hi Christian, RFC 4647 defines The Language Priority List [1]. The use of java.util.List would be a natural fit, which is the reason why List is used. But use of Iterable does work (as API design). The parameter name `priorityIterable' sounds a bit odd, though. Does

Re: i18n dev Additional source to guess the local timezone ID on linux

Hi Omair, /etc/sysconfig/clock used to be supported, but it was removed in JDK 7. The problem is discussed in bug #6456628. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456628 Have you tested your fix on all Red Hat-like distros, including some older releases, with all the time zone

Re: RFR: 6614237: missing codepage Cp290 at java runtime

Looks good. Masayoshi On 8/9/2013 4:19 AM, Xueming Shen wrote: Thanks Masayoshi, good catch, yes, those two aliases should be included. Webrev has been updated according. webrev: http://cr.openjdk.java.net/~sherman/6614237/webrev/ -Sherman On 08/04/2013 10:17 PM, Masayoshi Okutsu wrote: Hi

hg: jdk8/tl/jdk: 8015986: Incorrect Localization of HijrahChronology

Changeset: 0beaa65c90c8 Author:okutsu Date: 2013-08-08 13:51 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0beaa65c90c8 8015986: Incorrect Localization of HijrahChronology Reviewed-by: naoto Contributed-by: scolebou...@joda.org, roger.ri...@oracle.com !

Re: RFR: 6614237: missing codepage Cp290 at java runtime

Hi Sherman, IANA seems to define the following aliases for IBM290. cp290 EBCDIC-JP-kana csIBM290 The alias table should include EBCDIC-JP-kana and csIBM290 as well? Otherwise, the changes look good to me. Thanks, Masayoshi On 8/3/2013 5:53 AM, Xueming Shen wrote: Masayoshi, Would you

Re: RFR: java.time test bug

Looks good to me. Masayoshi On 7/30/2013 11:57 AM, Roger Riggs wrote: Please help review (and commit to jdk-tl or jdk) this java.time test bug 8021767 http://bugs.sun.com/view_bug.do?bug_id=8021767: test/java/time/tck/java/time/format/TCKFormatStyle.java failing Correct to use fixed

hg: jdk8/tl/jdk: 7177315: SimpleDateFormat parses wrong 2-digit year if input contains spaces

Changeset: 6975eea0b458 Author:okutsu Date: 2013-06-07 17:07 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6975eea0b458 7177315: SimpleDateFormat parses wrong 2-digit year if input contains spaces Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java +

hg: jdk8/tl/jdk: 7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 hi_IN.UTF-8

Changeset: a286ed046116 Author:okutsu Date: 2013-06-07 17:37 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a286ed046116 7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 hi_IN.UTF-8 Reviewed-by: peytoia !

Re: i18n dev RFR JDK-8013386: (tz) Support tzdata2013c

On 5/10/2013 3:30 PM, Xueming Shen wrote: On 5/9/13 9:57 PM, Masayoshi Okutsu wrote: Do we still need to keep the old javazic code in JDK8? It's a maintenance burden to maintain both, isn't it? While it's a burden, but somehow it serves as a test case pretty well. The transitions are being

Re: i18n dev RFR JDK-8013386: (tz) Support tzdata2013c

Do we still need to keep the old javazic code in JDK8? It's a maintenance burden to maintain both, isn't it? I'm concerned about the 24:00 fix. Is there any way to produce the correct rules without hard coding time zone IDs? Masayoshi On 5/10/2013 8:24 AM, Xueming Shen wrote: Hi Sean,

Re: Please review: surrogate fiddle

Thank you for catching this bug. AbstractStringBuilder.codePointAt(int) should have called Character.codePointAt(char[], int, int). As for duplicating code, I originally duplicated similar code everywhere for performance. But someone told me probably during code review that hotspot inlining

Re: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone

Looks good to me. Masayoshi On 2/19/2013 3:58 PM, Joe Darcy wrote: Hello, Please review these two simple fixes for javadoc warnings I noticed during a build (I'll file a bug after getting a review): diff -r bcde0486261e src/share/classes/java/time/format/DateTimeFormatterBuilder.java ---

Re: [Review Request] 8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list

The change is fine. But it's neither the spec nor guaranteed in the previous implementation to return a sorted list. The caller needed to sort the return value if a sorted list is required. Masayoshi On 2/14/2013 4:02 AM, Xueming Shen wrote: Hi, This is the regression triggered by my

hg: jdk8/tl/jdk: 4745761: (cal) RFE: Support builder for constructing Calendar

Changeset: 6ca6b6f07653 Author:okutsu Date: 2013-01-21 12:04 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ca6b6f07653 4745761: (cal) RFE: Support builder for constructing Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java !

hg: jdk8/tl/jdk: 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI; ...

Changeset: 3c1a440a1e12 Author:okutsu Date: 2013-01-21 15:41 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1a440a1e12 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI 8006509: Add more calendar symbol names from CLDR Reviewed-by: peytoia !

hg: jdk8/tl/jdk: 8005471: DateFormat: Time zone info is not localized when adapter is CLDR

Changeset: 4ad38db38fff Author:okutsu Date: 2012-12-28 14:13 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad38db38fff 8005471: DateFormat: Time zone info is not localized when adapter is CLDR Reviewed-by: peytoia !

hg: jdk8/tl/jdk: 8005561: typo in Calendar

Changeset: f3ac419e2bf0 Author:okutsu Date: 2012-12-28 16:39 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3ac419e2bf0 8005561: typo in Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java

Re: i18n dev RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo

I was wondering if you plan to address the review comment by David. If that part gets addressed, I think the test case change is no longer required. Otherwise, your change to the test program is fine with me. Thanks, Masayoshi On 2012/11/28 21:59, Staffan Larsen wrote: Did we conclude that

hg: jdk8/tl/jdk: 8000986: Split java.util.spi.CalendarDataProvider into week parameters and field names portions

Changeset: 5d3f8f9e6c58 Author:okutsu Date: 2012-11-12 11:12 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d3f8f9e6c58 8000986: Split java.util.spi.CalendarDataProvider into week parameters and field names portions Reviewed-by: naoto ! make/java/java/FILES_java.gmk !

hg: jdk8/tl/jdk: 6380549: (rb) ResourceBundle.Control global binding support

Changeset: 4419c8f0b2f2 Author:okutsu Date: 2012-06-19 16:21 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4419c8f0b2f2 6380549: (rb) ResourceBundle.Control global binding support Reviewed-by: naoto ! make/java/java/FILES_java.gmk !

Re: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled

Hi Deven, Sorry. I didn't review the test case... You can use applet to write a manual test. You will find some manual tests under test/java/awt such as: test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.{html,java} Thanks, Masayoshi On 5/25/2012 4:41 PM, Deven You wrote: Hi

Re: hg: jdk8/tl/jdk: 7094176: (tz) Incorrect TimeZone display name when DST not applicable / disabled

On 5/25/2012 6:37 PM, Alan Bateman wrote: On 25/05/2012 10:32, Masayoshi Okutsu wrote: Hi Deven, Sorry. I didn't review the test case... You can use applet to write a manual test. You will find some manual tests under test/java/awt such as: test/java/awt/TextField/ScrollSelectionTest

Re: i18n dev RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

fd needs to be closed when fstat or malloc failed? Thanks, Masayoshi On 3/13/2012 12:22 AM, Alan Bateman wrote: On 12/03/2012 15:11, Seán Coffey wrote: Yes - good catch. I hadn't tested the sym link being a relative path. We should always open whatever is pointed to from

Re: i18n dev RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

Looks good to me. Masayoshi On 3/13/2012 6:38 PM, Seán Coffey wrote: Update made. Hopefully the last iteration ;) http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.4/ regards, Sean. On 13/03/2012 05:59, Masayoshi Okutsu wrote: fd needs to be closed when fstat or malloc failed

Re: RFR: 7133138 Improve io performance around timezone lookups

The fix looks good. Thanks, Masayoshi On 2/22/2012 3:19 AM, Seán Coffey wrote: I've worked with Masayoshi on this issue. Hoping to push to JDK8 and backport to 7u and a jdk6 once baked for a while. Some windows boxes were showing performance issues when attempting to iterate through all

Re: i18n dev Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

are discussing) On 02/09/2012 12:26 AM, Masayoshi Okutsu wrote: First of all, is this really a Java SE bug? The usage of OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo method in the bug report doesn't seem to be able to deal with any stateful encodings. Masayoshi On 2/9

Re: i18n dev Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

First of all, is this really a Java SE bug? The usage of OutputSteamWriter in JavaMail seems to be wrong to me. The writeTo method in the bug report doesn't seem to be able to deal with any stateful encodings. Masayoshi On 2/9/2012 3:26 PM, Xueming Shen wrote: Hi This is a long standing

hg: jdk8/tl/jdk: 7130335: Problem with timezone in a SimpleDateFormat

Changeset: 7aa5ddfa3c9d Author:okutsu Date: 2012-01-27 14:58 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7aa5ddfa3c9d 7130335: Problem with timezone in a SimpleDateFormat Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java +

hg: jdk8/tl/jdk: 7122054: (tz) Windows-only: tzmappings needs update for KB2633952

Changeset: 1c4fffa22930 Author:okutsu Date: 2011-12-21 17:09 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c4fffa22930 7122054: (tz) Windows-only: tzmappings needs update for KB2633952 Reviewed-by: peytoia ! src/windows/lib/tzmappings

hg: jdk8/tl/jdk: 7117487: Warnings Cleanup: some i18n classes in java.util and sun.util

Changeset: f2a5d0001f15 Author:okutsu Date: 2011-12-03 10:58 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2a5d0001f15 7117487: Warnings Cleanup: some i18n classes in java.util and sun.util Reviewed-by: lancea, naoto ! src/share/classes/java/util/Date.java !

hg: jdk8/tl/jdk: 2 new changesets

Changeset: cd6d236e863b Author:okutsu Date: 2011-11-16 12:57 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd6d236e863b 7111903: (tz) Windows-only: tzmappings needs update for KB2570791 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 1266e72f7896 Author:

Re: Patch to expand tz checking scope in TimeZone_md.c

10:27 PM, Masayoshi Okutsu wrote: Hi Jonathan, IIRC, the difference came from some behavioral difference between the Linux and Solaris libc date-time functions and/or the date command, and TimeZone_md.c tries to follow the difference. But the code was written long ago. The difference may

hg: jdk8/tl/jdk: 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11; ...

Changeset: 2bc80ba6f4a4 Author:okutsu Date: 2011-10-05 15:13 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bc80ba6f4a4 7092679: (tz) Java getting wrong timezone/DST info on Solaris 11 6984762: Invalid close of file descriptor '-1' in findZoneinfoFile Reviewed-by: coffeys,

  1   2   >