Result: New Internationalization Group Lead: Naoto Sato

Voting for Internationalization Group Lead Naoto Sato [1] is now closed. Yes: 1 No: 0 Abstain: 0 According to the Bylaws definition of Simple Majority, this is sufficient to approve the new Group Lead. The OpenJDK Lead will ask the Governing Board to ratify this nomination. Masayoshi Okutsu

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

Resigning as the Internationalization Group Lead

I am resigning as the lead of this group because I'm leaving the company. Thanks, Masayoshi

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: Request for Review: JDK-8165296: update i18n test cases in test/java/util/

Looks good to me. Masayoshi On 11/14/2016 4:13 PM, Nancy Nigam wrote: Hi, Please review the fix for JDK-8165296. Bug : https://bugs.openjdk.java.net/browse/JDK-8165296 Webrev: http://cr.openjdk.java.net/~nishjain/Nancy/8165296/webrev.07/

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

RFR: 8165804: Revisit the way of loading BreakIterator rules/dictionaries

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

Re: RFR: JDK-8167992 : Update documentation of java.util.Date class

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.Da

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:JDK-8166993: Typo in java.util.Locale

+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

Re: RFR:JDK-8146750:java.time.Month.getDisplayName() return incorrect narrow names with JRE provider.

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 :

Re: [OpenJDK 2D-Dev] RFR: 8162531solaris.fontconfig.properties needs updating

Looks good to me. Masayoshi On 9/24/2016 2:00 PM, Philip Race wrote: 1) version change is only if the format is incompatible - so no change there. 2) paths being absent is not a new issue. It has always been the case that a file is not present on a system at runtime. This was historically

Re: Review Request for JDK-8165984: ResourceBundle lookup fields not completely thread-safe

+1 Masayoshi On 9/17/2016 2:00 AM, Naoto Sato wrote: Looks good. BTW, I believe making it "final" means to make sure every threads are guaranteed to see the same value, not because it is not changed after the construction. Naoto On 9/16/16 2:09 AM, Nishit Jain wrote: Hi, Please review

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: Request for Review: JDK-8164791: update i18n test cases in test/java/text/Format

Looks good. Masayoshi On 9/2/2016 6:20 PM, Nancy Nigam wrote: Hi, Please review the fix for JDK-8164791. Bug : https://bugs.openjdk.java.net/browse/JDK-8164791 Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8164791/webrev.06/ Fix : Updated I18n test cases in test/java/text/Format for

RFR: 8157792: After Integrating tzdata2016d the test/sun/util/calendar/zi/TestZoneInfo310.java fails for "Asia/Oral" and "Asia/Qyzylorda" Timezones

Hi, Please review the fix for JDK-8157792. When a zone item wasn't used for any standard-daylight transition, the zone information was discarded. Therefore, its GMT offset change wasn't taken. Issue: https://bugs.openjdk.java.net/browse/JDK-8157792 Webrev:

Re: RFR: JDK-8163362-Reconsider reflection usage in java.awt.font.JavaAWTFontAccessImpl class

Looks good to me. Masayoshi On 8/22/2016 1:26 PM, Rachna Goel wrote: Hi, Please review fix for JDK-8163362. https://bugs.openjdk.java.net/browse/JDK-8163362 Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8163362/webrev.01/ This is a cleanup fix in which Reflection usage in

Re: RFR: JDK-8135055.java.util.Date.after(java.sql.Timestamp ) does not return correct results

Looks good to me. Masayoshi On 8/22/2016 1:51 PM, Rachna Goel wrote: Hi, Please review fix for JDK-8135055. Bug: https://bugs.openjdk.java.net/browse/JDK-8135055 Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8135055/webrev.02/ Fix is to return getTime() if argument to getMillisOf() is

Re: Review Request:JDK-8163350-LocaleProviderAdapter Preference list retrieved is wrong, when -Djava.locale.providers=COMPAT

Looks good to me. Masayoshi On 8/22/2016 1:10 PM, Rachna Goel wrote: Hi Masayoshi, Thanks for the review. please have a look at updated webrev http://cr.openjdk.java.net/~rgoel/jdk-8163350/webrev.04/ Thanks, Rachna On 8/16/16 1:16 PM, Masayoshi Okutsu wrote: Hi Rachna, The fix looks

Re: Review Request:JDK-8163350-LocaleProviderAdapter Preference list retrieved is wrong, when -Djava.locale.providers=COMPAT

Hi Rachna, The fix looks good to me. But the test should be changed. - It's unnecessary to statically import sun.util.locale.provider.LocaleProviderAdapter.Type. - Variable name PreferenceList should be preferenceList. - No need to initialize preferenceList with an ArrayList. Thanks,

Re: Review Request for JDK-8129555: DateFormatSymbols: month-related methods must refer to Calendar constants

Looks good to me. Masayoshi On 8/16/2016 2:26 PM, Nishit Jain wrote: Hi, Please review the fix for JDK-8129555 Bug: https://bugs.openjdk.java.net/browse/JDK-8129555 Webrev: http://cr.openjdk.java.net/~nishjain/8129555/webrev.02/ Fix: Added references to the Calendar constants in the api

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

le, bundle.loadTime); In my opinion, the change of the semantics of ResourceBundle.clearCache(ClassLoader) could be tolerated if the invocation of that method was not a requirement for application containers to be able to unload the app's class loader. With my proposed change to cachi

Re: Review Request for JDK-7153347: System read/stat/open calls should be hardened to handle EINTR

+1 Masayoshi On 8/1/2016 11:47 PM, Langer, Christoph wrote: Hi Nishit, this looks good and aligns with other places which were hardened for EINTR. But I'm not a reviewer, so you need to get a higher vote, still :) Best regards Christoph -Original Message- From: i18n-dev

Re: Review Request : JDK-8066652 : Default TimeZone is GMT not local if user.timezone is invalid on Mac OS

+1 Masayoshi On 8/1/2016 6:40 AM, Langer, Christoph wrote: Thanks Rachna, that's fine now :) -Original Message- From: i18n-dev [mailto:i18n-dev-boun...@openjdk.java.net] On Behalf Of Rachna Goel Sent: Sonntag, 31. Juli 2016 19:47 To: i18n-dev@openjdk.java.net Subject: Re: Review

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

being GCed immediately. I can prototype such caching if you like. Regards, Peter On 07/22/2016 06:07 AM, Masayoshi Okutsu wrote: Hi Peter, Thank you for your suggestion. Actually CacheKey is used for storing information required to load resource bundles during a ResourceBundle.getBundl

Re: RFR: 8161203: ResourceBundle.getBundle performance regression

of code could unintentionally produce a class loader leak. To prevent that, I would somehow mark the clone so that any attempt to invoke getProviders() on the clone would throw IllegalStateException. Regards, Peter On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote: Hi, Please review the fix for JDK

RFR: 8161203: ResourceBundle.getBundle performance regression

Hi, Please review the fix for JDK-8161203. The fix is to lazily load ResourceBundleProviders. It's not necessary to load providers before cache look-up. Issue: https://bugs.openjdk.java.net/browse/JDK-8161203 Webrev: http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 Thanks, Masayoshi

Re: Review Request-JDK-8154797:Localization data for "GMT"

+1 Masayoshi On 7/14/2016 2:15 AM, Naoto Sato wrote: +1 Naoto On 7/13/16 10:14 AM, Rachna Goel wrote: Hi Naoto, Thanks for the review. Please have a look at updated webrev : http://cr.openjdk.java.net/~rgoel/JDK-8154797/webrev.05/ Thanks, Rachna On 7/13/2016 9:04 PM, Naoto Sato wrote:

Re: Review Request for JDK-8055900: j.t.SimpleDateFormat spec needs to be clarified regarding month patterns

+1 Masayoshi On 7/7/2016 5:07 PM, Yuka Kamiya wrote: Hi, The fix looks okay to me. Thanks, -- Yuka On 2016/07/07 16:17, Nishit Jain wrote: Hi, Please review the fix for JDK-8055900 Bug: https://bugs.openjdk.java.net/browse/JDK-8055900 Webrev:

RFR: 8136356: Add time zone mappings on Windows

Hi, Please review the fix for JDK-8136356. This fix addresses time zone changes of KB3039024, KB3148851, KB914387, and KB3162835. Issue: https://bugs.openjdk.java.net/browse/JDK-8136356 Webrev: http://cr.openjdk.java.net/~okutsu/9/8136356/webrev.00 Thanks, Masayoshi

RFR: 8159943: JavaTimeSupplementary resource bundles need update

Hi, Please review the fix for JDK-8159943. There were some problems in a tool to generate resource bundles. In addition, src/java.base/share/classes/sun/util/resources/LocaleData.java was fixed to look up resource bundles in java.base correctly. Issue:

Re: Review request : JDK-8158504 - test/sun/util/locale/provider/Bug8038436.java fails

+1 Masayoshi On 6/28/2016 2:12 AM, Naoto Sato wrote: I'd wrap long lines, others look good to me. Naoto On 6/27/16 2:46 AM, Rachna Goel wrote: Hi Naoto, Thanks for the review. I have modified test as per suggestions. Please have a look at :

RFR: 8159766: "Switching encoding from UTF-8 to ISO-8859-1" log message should be trace/debug message

Hi, Please review the fix for JDK-8159766. The logging code has been removed after all. No additional regression test. The message should no longer be logged to the .jtr file with java/util/ResourceBundle/UTF8Properties/CodePointTest.java. Issue:

Re: [9] RFR: 8159781: jlink --include-locales fails with java.util.regex.PatternSyntaxException

If the long pattern string is avoided, it'll be unnecessary to use "%%" and replaceAll? I'm also concerned to keep concatenating strings to produce a long string (rather than using a StringBuilder). Would that be the reason to put -verbose:gc in the test program? Use of List will simplify the

Re: Review Request for JDK-8159420 : The LanguageRange.parse() method is throwing IllegalArgumentException in Turkish Locale

Looks good. Thanks, Masayoshi On 6/17/2016 5:16 PM, Nishit Jain wrote: Hi, Please review the fix for JDK-8159420 Bug: https://bugs.openjdk.java.net/browse/JDK-8159420 Webrev: http://cr.openjdk.java.net/~nishjain/8159420/webrev.04/ Fix: Changed the toLowerCase() method on language-ranges and

Re: RFR: 8158272 & 8158468 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)

I've been waiting for JDK-8159206 to be fixed. But this test still fails after the JDK-8159206 fix. I've filed JDK-8159781 for the failure and pushed this test fix with the following ProblemList.txt change: diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++

Re: Review Request for JDK-8135061: java.util.Locale#lookup throws java.lang.StringIndexOutOfBoundsException for range having '-' as second character

Looks good to me. Masayoshi On 6/13/2016 6:54 PM, Nishit Jain wrote: Hi, Please review the fix for JDK-8135061 Bug: https://bugs.openjdk.java.net/browse/JDK-8135061 Webrev: http://cr.openjdk.java.net/~nishjain/8135061/webrev.01/ Fix : Added a check on the lastIndexOf "-" before using

Re: RFR: 8158272 & 8158468 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)

On 6/11/2016 5:53 AM, Mandy Chung wrote: On Jun 10, 2016, at 12:08 AM, Masayoshi Okutsu <masayoshi.oku...@oracle.com> wrote: (re-sending to include jigsaw-dev) Hi, Please review fixes for 8158272 and 8158468. The test had several problems. : Webrev: http://cr.openjdk.java.net/~ok

Re: Review Request for JDK-8040211: Update LSR datafile for BCP 47

Looks good to me. Masayoshi On 6/10/2016 3:20 PM, Nishit Jain wrote: Hi, Please review the fix for JDK-8040211 Bug: https://bugs.openjdk.java.net/browse/JDK-8040211 Webrev: http://cr.openjdk.java.net/~nishjain/8040211/webrev.02/ Fix: Updated the Language Subtag Registry data provided by

RFR: 8158272 & 8158468 (tools/jlink/plugins/IncludeLocalesPluginTest.java bug fixes)

Hi, Please review fixes for 8158272 and 8158468. The test had several problems. - A child process doesn't inherit IO. Any outputs from the child process are not logged. - The exit code of a child process is ignored. The exit code needs to be checked by the test. - A child process should use

Re: Review Request for JDK-8047780: Locale.LanguageRange() throws an undocumented IAE when range is ill-formed.

Looks good. Masayoshi On 6/7/2016 2:20 PM, Nishit Jain wrote: Hi, Please review the fix for JDK-8047780 Bug: https://bugs.openjdk.java.net/browse/JDK-8047780 Webrev: http://cr.openjdk.java.net/~nishjain/8047780/webrev.01/ Fix: Added in the api spec that the IllegalArgumentException can be

Re: Review Request for JDK-8072099: Format "ha" is unable to parse hours 10-12

+1 On 5/31/2016 4:14 PM, Yuka Kamiya wrote: Hi, The fix looks good to me. Thanks, -- Yuka On 2016/05/31 15:00, Nishit Jain wrote: Hi, Please review the fix for JDK-8072099. Webrev: http://cr.openjdk.java.net/~nishjain/8072099/webrev.03/ Bug:

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: Review Request for JDK-8158025: Typo in java.util.Locale

Looks good to me. Masayoshi On 5/30/2016 3:00 PM, Nishit Jain wrote: Hi, Please review the fix for JDK-8158025. Webrev : http://cr.openjdk.java.net/~nishjain/8158025/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158025 Fix: corrected a small typo in Locale.java. Regards,

RFR: 8039565: Remove test exclusion for java/util/ResourceBundle/RestrictedBundleTest.java

Hi, Please review the fix for JDK-8039565. I don't think it's worth keeping this old test and decided to remove it. Issue: https://bugs.openjdk.java.net/browse/JDK-8039565 Webrev: http://cr.openjdk.java.net/~okutsu/9/8039565/webrev.00 Thanks, Masayoshi

Re: Review Request for JDK-8145136:Upgrade CLDR locale data

Other than the copyright year things, all looks good to me. I don't think further review is required for copyright update. Masayoshi On 5/28/2016 3:25 AM, Naoto Sato wrote: Hi Rachna, Here are my comments to the webrev (I am assuming the tool that extracts JavaTime*.java are working

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: 8031145: Re-examine closed i18n tests to see it they can be moved to the jdk repository.

On 5/26/2016 7:07 PM, Alan Bateman wrote: On 26/05/2016 10:41, Masayoshi Okutsu wrote: Naoto pointed out that test/java/text/Format/common/*Format.props should have the copyright header. Unfortunately, test/java/text/Format/common/PParser.java, which parses the .props files, doesn't support

Re: RFR: 8031145: Re-examine closed i18n tests to see it they can be moved to the jdk repository.

/8031145/webrev.01. On 5/24/2016 11:49 PM, Masayoshi Okutsu wrote: Changed all binary files (serialized objects) into hex dump text files (with ".ser.txt" suffix) and added a utility class to read it as an InputStream. Updated webrev: http://javasoft.jp.oracle.com/~mokutsu/9/8031145

RFR: 8031145: Re-examine closed i18n tests to see it they can be moved to the jdk repository.

Hi, Please review changes for JDK-8031145 that is to open closed i18n tests. There are many old tests which should be cleaned up. I did some, but there are still many. Issue: https://bugs.openjdk.java.net/browse/JDK-8031145 Webrev: http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.00/

Re: Review Request for JDK-8149452: j.t.SimpleDateFormat.getDateFormatSymbols().getZoneStrings() returns incorrect result for some time zones

Looks good to me. Masayoshi On 5/18/2016 6:38 PM, Nishit Jain wrote: Hello All, Please review the fix for JDK-8149452 Bug: https://bugs.openjdk.java.net/browse/JDK-8149452 Webrev: http://cr.openjdk.java.net/~nishjain/8149452/webrev.01/ Fix: Made some changes to the CLDRConverter.java to

Re: Review Request for JDK-7102969 and JDK-8157138: "currency.properties supercede..." and "Error while fetching currency instance..."

+1 Masayoshi On 5/19/2016 5:40 PM, Yuka Kamiya wrote: Hi Nishit, The fix looks okay to me. Thanks, -- Yuka On 2016/05/19 16:04, Nishit Jain wrote: Hello All, Please review the updated webrev synced with the latest repository.

Re: Review Request for JDK-8150324: java/util/Currency/CurrencyTest.java does not restore default TimeZone

Looks good to me. Masayoshi On 4/11/2016 9:18 PM, Nishit Jain wrote: Hi, Thanks for pointing that out. Please review the updated webrev at the below mentioned link http://cr.openjdk.java.net/~peytoia/Nishit/8150324/webrev.02/ Regards, Nishit Jain On 4/11/2016 4:46 PM, Yuka Kamiya wrote:

RFR: 8153836: java/util/ResourceBundle/Bug6299235Test.sh depends on java.desktop

Hi all, Please review the fix for JDK-8153836. Issue: https://bugs.openjdk.java.net/browse/JDK-8153836 Webrev: http://cr.openjdk.java.net/~okutsu/9/8153836/webrev.00/ Thanks, Masayoshi

Re: RFR: JDK-7129443: (cal) Difference between comment and implementation of DAY_OF_WEEK_IN_MONTH

Looks good to me. Masayoshi On 4/8/2016 1:40 PM, Yuka Kamiya wrote: > Hi, > > I'm sending this RFR in place of Nishit Jain.This is a small doc change. > > Please review the webrev for the JDK-7129443 > > Bug: https://bugs.openjdk.java.net/browse/JDK-7129443 > Webrev:

Re: RFR: 8151431: DateFormatSymbols triggers this.clone() in the constructor

in the cache. Right. But that one is too tricky to handle there. - DateFormatSymbolsCloneTest.java: import sentence for the Locale class can be removed. Good catch. Fixed. Masayoshi Naoto On 4/6/16 2:10 AM, Masayoshi Okutsu wrote: Hi all, Please review the fix for JDK-8151431. clone

RFR: 8151431: DateFormatSymbols triggers this.clone() in the constructor

Hi all, Please review the fix for JDK-8151431. clone() is no longer called to create a cache entry. Issue: https://bugs.openjdk.java.net/browse/JDK-8151431 Webrev: http://cr.openjdk.java.net/~okutsu/9/8151431/webrev.00/ Thanks, Masayoshi

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: [9] RFR: 8153041: Remove unused redundant parameter in CLDRConverter

Looks good to me. Masayoshi On 3/31/2016 2:03 AM, Naoto Sato wrote: Hello, Please review this simple fix to the subject bug: https://bugs.openjdk.java.net/browse/JDK-8153041 The fix is located at: http://cr.openjdk.java.net/~naoto/8153041/webrev.00/ Naoto

Re: RFR: 8152817: Locale data loading fails silently when running with a security manager

/ Thanks, Masayoshi On 3/31/2016 8:56 AM, Masayoshi Okutsu wrote: On 3/31/2016 12:54 AM, Alan Bateman wrote: On 30/03/2016 16:48, Mandy Chung wrote: On Mar 30, 2016, at 8:40 AM, Masayoshi Okutsu <masayoshi.oku...@oracle.com> wrote: Hello, Please review the fix for JDK-8152817. The fix is t

Re: RFR: 8152817: Locale data loading fails silently when running with a security manager

On 3/31/2016 12:54 AM, Alan Bateman wrote: On 30/03/2016 16:48, Mandy Chung wrote: On Mar 30, 2016, at 8:40 AM, Masayoshi Okutsu <masayoshi.oku...@oracle.com> wrote: Hello, Please review the fix for JDK-8152817. The fix is to load locale data from its own module without c

RFR: 8152817: Locale data loading fails silently when running with a security manager

Hello, Please review the fix for JDK-8152817. The fix is to load locale data from its own module without calling ResourceBundleProviderSupport.loadResourceBundle. I changed the synopsis of the JBS issue because it's a general issue of loading locale data under a security manager, and the

RFR: 8152077: (cal) Calendar.roll does not always roll the hours during daylight savings changes

Hello, Please review the fix for JDK-8152077. There's a bug in the roll method around the standard/daylight saving time transitions. I've changed the implementation to perform the "roll" operation based on the wall-clock time rather than the UTC time (the offset from the Epoch). Issue:

Re: RFR: 8151876: (tz) Support tzdata2016b

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

Re: Review Request for JDK-8150432: java/util/Locale/LocaleProviders.sh failed on Win10.

Looks good to me. Masayoshi On 3/28/2016 3:15 PM, Rachna Goel wrote: Hi all, Please review a small fix for JDK-8150432. Bug and proposed fix are located at below links respectively. https://bugs.openjdk.java.net/browse/JDK-8150432 http://cr.openjdk.java.net/~rgoel/8150432/webrev/

Re: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width

you in advance, Dmitry On 20/03/2016 07:11, Masayoshi Okutsu wrote: The fix looks Okay to me. But there should be a regression test for this particular case? I wonder if we can have a test case to verify width(s) of monospaced glyphs. Masayoshi On 3/18/2016 4:54 AM, Phil Race wrote: I think you

Re: [OpenJDK 2D-Dev] [9] Review request for 8073400: Some Monospaced logical fonts have a different width

The fix looks Okay to me. But there should be a regression test for this particular case? I wonder if we can have a test case to verify width(s) of monospaced glyphs. Masayoshi On 3/18/2016 4:54 AM, Phil Race wrote: I think you are still waiting on i18n to reply here since the exclusion

Re: RFR: 8148446: (tz) Support tzdata2016a

Looks good to me. Masayoshi On 2/4/2016 5:55 PM, Ramanand Patil wrote: Hi Masayoshi/all, Please review the updated Webrev at: http://cr.openjdk.java.net/~rpatil/8148446/webrev.01/ Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Thursday, February 04, 2016 12:17 PM

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-dev@openjdk.java.net Cc: core-libs-...@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: RFR: JDK-8026766: Add toString() to j.u.Locale.LanguageRange.

Looks good to me. Masayoshi On 1/15/2016 1:18 PM, Yuka Kamiya wrote: > Hi, > > Please review this simple fix for JDK-8026766: Add toString() to > j.u.Locale.LanguageRange. > https://bugs.openjdk.java.net/browse/JDK-8026766 > > http://cr.openjdk.java.net/~peytoia/8026766/webrev.00/ > > Of course,

Re: [9] RFR: Host Locale Provider Adapter fixes on Windows

The copyright year should be 2016 now. Otherwise, the fixes look OK to me. Masayoshi On 1/5/2016 4:10 AM, Naoto Sato wrote: Hello, I fixed several bugs in Windows' host locale provider adapter: 8039301: [ja] Host Locale Provider uses non-translated Calendar field names 8039969: Old Korean

Re: Review Request:JDK-8025547-Locale.toString() documentation error.

Looks good to me. Masayoshi On 12/9/2015 4:09 PM, Rachna Goel wrote: Hi all, Kindly review small documentation fix in Locale.toString() method. Bug : https://bugs.openjdk.java.net/browse/JDK-8025547 webrev: http://cr.openjdk.java.net/~rgoel/8025547/webrev.02/

Re: [9] RFR: 8141243: Unexpected timezone returned after parsing a date

rdered map? In other words, should we do the same for "UTC" at the line 140? Naoto On 11/20/15 12:24 AM, Masayoshi Okutsu wrote: Hello, This is a follow up of the fix for JDK-8141243 done by Ramanand. I've changed resources so that time zone ID "UTC" is picked up by SimpleDate

Re: Review Request: JDK-8073211 javadoc of Format parseObject methods should specify NullPointerExceptions

Looks good. Masayoshi On 11/20/2015 7:20 PM, Naveen Kumar wrote: Hi, Please consider this updated webrev.01 for the review of bug JDK-8073211 Bug:https://bugs.openjdk.java.net/browse/JDK-8073211 webrev: http://cr.openjdk.java.net/~okutsu/naveen/8073211/webrev.01/ updates

[9] RFR: 8141243: Unexpected timezone returned after parsing a date

Hello, This is a follow up of the fix for JDK-8141243 done by Ramanand. I've changed resources so that time zone ID "UTC" is picked up by SimpleDateFormat before Antarctica/Troll. issue: https://bugs.openjdk.java.net/browse/JDK-8141243 webrev:

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: 8134720: Lazy initialization support for currency names in DecimalFormatSymbols

Looks good to me. Masayoshi On 10/23/2015 1:29 AM, Naoto Sato wrote: Hello, Please review yet another fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8134720 The proposed change is located at: http://cr.openjdk.java.net/~naoto/8134720/webrev.00/ The fix also includes

Re: [9] RFR: 8138613: Remove SPI locale provider adapter from the default provider list

Looks good to me. Masayoshi On 10/3/2015 7:48 AM, Naoto Sato wrote: Hello, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8138613 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8138613/webrev.00/ Naoto

[9] RFR: 8138663: Missing @build in test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java

Hello, Please review this simple fix for 8138663. RoundingAndPropertyTest.java uses golden data classes which are not recomplied when updated. Bug: https://bugs.openjdk.java.net/browse/JDK-8138663 Webrev: http://cr.openjdk.java.net/~okutsu/9/8138663/webrev.00 Thanks, Masayoshi

Re: Review request: JDK-8081794 ParsePosition getErrorIndex returns 0 for TimeZone parsing problem

Looks good to me. I will push the fix for you. Thanks, Masayoshi On 9/29/2015 7:12 PM, Naveen Kumar wrote: Hi, Please consider this updated webrev.01 for the review of bug JDK-8081794. Bug: https://bugs.openjdk.java.net/browse/JDK-8081794 Webrev:

Re: [9] RFR: 8136518: java/util/TimeZone/CLDRDisplayNamesTest.java fails for de.

Looks good to me. Masayoshi On 9/24/2015 5:55 AM, Naoto Sato wrote: Hello, Please review this simple change to a test case: https://bugs.openjdk.java.net/browse/JDK-8136518 http://cr.openjdk.java.net/~naoto/8136518/webrev.00/ The fix is to specify English on obtaining a TimeZone instance.

Re: i18n dev [9] RFR: 8134250: Create unit tests for CLDR unique features

Looks good to me. Thanks for adding this unit test. Masayoshi On 8/25/2015 7:18 AM, Naoto Sato wrote: Hello, Please review the changes for the following issue: https://bugs.openjdk.java.net/browse/JDK-8134250 It is just adding more unit testcases for the JEP 252. The proposed changeset is

Re: i18n dev FW: RFR(XS): 8133830: [solaris] Fix for potential memory leak in TimeZone_md.c, function findJavaTZ_md()

Looks good to me too. Thank you for fixing this bug. Aleksej, it's great if you can sponsor this fix. Thanks, Masayoshi On 8/25/2015 1:27 AM, Aleksej Efimov wrote: Hi Christoph, I can sponsor your change. Fix looks good to me (but I'm not a reviewer). With Best Regards, Aleksej On

Re: i18n dev [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 [9] RFR: 8133044: [TESTBUG] CLDRDisplayNameTest uses deprecated API, fails

Looks good to me. Masayoshi On 8/7/2015 8:37 AM, Naoto Sato wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8133044 The fix is to just remove the offending test cases which don't always correct. It is located at:

Re: i18n dev [9] RFR: 8132494: Wrong CLDR resource bundle names for legacy ISO language codes

Looks good to me. Masayoshi On 8/5/2015 5:31 AM, Naoto Sato wrote: Hello, Please review the changes for the following issue: https://bugs.openjdk.java.net/browse/JDK-8132494 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8132494/webrev.00/ Naoto

Re: i18n dev [9] RFR: 8129881, 8130845, 8132125

The i18n changes look good to me. Masayoshi On 8/4/2015 7:10 AM, Naoto Sato wrote: Hello, Please review the changes for the following issues that are the regressions for fixing 8008577: 8129881: 8008577 breaks Nashorn test (https://bugs.openjdk.java.net/browse/JDK-8129881) 8130845: Change

Re: i18n dev [9] RFR: JDK-8027607, (rb) Provide UTF-8 based properties resource bundles (JEP-226)

Looks good to me. Masayoshi On 7/25/2015 6:32 AM, Naoto Sato wrote: Hello, Please review the changes for the following issue, which is the implementation part of the JEP-226 (https://bugs.openjdk.java.net/browse/JDK-8043553) https://bugs.openjdk.java.net/browse/JDK-8027607 The webrev is

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: i18n dev [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252)

://cr.openjdk.java.net/~naoto/8008577/webrev.01/ As to the 3rd comment below, I did not modify it because that would simply duplicate the same piece of code in each getCandidateLocales() implementation (from the current location). Naoto On 6/19/15 1:53 AM, Masayoshi Okutsu wrote: Sorry for taking time

Re: i18n dev [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252)

Looks good to me. Masayoshi On 6/25/2015 1:15 AM, Naoto Sato wrote: Thanks. Here is the diff from webrev.01 to address your comment: http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/b8faab65bb62 Naoto On 6/24/15 2:16 AM, Masayoshi Okutsu wrote: applyParentLocales() sets parentLocalesMap

Re: i18n dev 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 [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252)

Sorry for taking time. Here are my comments. src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: - The year range of the first line of the copyright header should be 2015, for the new ones and 2013, 2015, for the updated ones. - I wonder if

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 [8u60] RFR: 7044727: (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session

name getDynamicTimeZoneInfo for the function name and the proc address variable name (initially I thought if it were a recursive call). Otherwise it looks good to me. Also approving the backport to 8u. Naoto On 4/17/15 1:16 AM, Masayoshi Okutsu wrote: Hello, Please review and approve the 8u

i18n dev [8u60] RFR: 7044727: (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session

Hello, Please review and approve the 8u version of the fix for JDK-7044727. This fix is different from the jdk9 one to be buildable and runnable on Windows XP. issue: https://bugs.openjdk.java.net/browse/JDK-7044727 8u webrev: http://cr.openjdk.java.net/~okutsu/8u/7044727/webrev.00/ jdk9

i18n dev [9] RFR: 7044727: (tz) TimeZone.getDefault() call returns incorrect value in Windows terminal session

Hello, Please review the fix for JDK-7044727. This fix supports time zone redirection for Windows terminal sessions. (There are still obsolete code for NT/86. But it's a lot of work to eliminate them.) issue: https://bugs.openjdk.java.net/browse/JDK-7044727 webrev:

  1   2   3   >