[8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

note that packaging changes that relate to Jigsaw module system aren't included in this changeset. Naoto Sato and Masayoshi Okutsu

Re: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

iles will break with all the filename or directory changes. But I hate to hold up your integration plans. I'd like to get some advice from Erik on this before saying anything further. -kto On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: Hello, Please review the JDK8 changes for JEP

Re: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

s 2 or 3, please give me the patch, and I will go ahead and merge them to my changeset. Naoto Other than that, I have no objections to the review. /Erik I'd like to get some advice from Erik on this before saying anything further. -kto On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: He

Re: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

on an internal review: http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ This includes: - a couple of fixes to the CLDR Converter - Added fallback for any bad SPI implementations which return null for requested instances. Still asking for review comments. Naoto On 8/8/12 2:13 PM, Naoto

Re: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

and JDK due to JSR292 changes, so it would be good to also add some space between those changes and these ones - if that is feasible. This isn't my call, I'm just airing concerns :) Thanks, David On 14/08/2012 7:43 AM, Naoto Sato wrote: Since I haven't heard any more comme

Re: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

ge to get the patch completed before I had to run. (webrev and mercurial wouldn't cooperate). I will get it done asap today. /Erik On 2012-08-13 23:43, Naoto Sato wrote: Since I haven't heard any more comments from Erik/Kelly, I would like to push the changeset without the new build in

Re: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

68528 LocaleServiceProvider needs to be aware of Locale extensions 7171372 (cal) locale's default Calendar should be created if unknown calendar is specified Please note that packaging changes that relate to Jigsaw module system aren't included in this changeset. Naoto Sato and Masayoshi Oku

Re: [8] Review request for 7196354 check-in jdk.tbom file to openjdk repo

Hi Michael, Looks like the list does not reflect the recent changes introduced by the re-organization of the locale data (sun/util/resources). To me, just keeping an eye on the files sounds error prone. Would it be possible to add some automated check, say in "jcheck"? Naoto On 9/10/12 2:2

[8]Review request: 8001231 : Move locale data out of rt.jar (except the US locale)

Hello, I need someone to review my changes to the following bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001231 The fix is to move locale data out of rt.jar into localedata.jar which will be optional in the compact profile (http://openjdk.java.net/jeps/161) The gist of the changes

Re: [8]Review request: 8001231 : Move locale data out of rt.jar (except the US locale)

Thank you for the review, Alan. On 10/31/12 3:06 AM, Alan Bateman wrote: I looked through the changes and they look fine to me, it's good to have this separation. Also good to see that you've also updated the makefiles for the new build system. If we were continuing with the old build system the

Re: Review Request: 8003177: build-infra: Compare reports diff in LocaleDataMetaInfo.class

My bad. This should have been fixed with 8001231. Looks good to me. Naoto On 11/8/12 8:40 AM, Erik Joelsson wrote: Small fix for class file diff that was introduced with the changes to locales. http://cr.openjdk.java.net/~erikj/8003177/webrev.01/

Re: [8] Code review request: 8000983 and 8003267

Here are my comments: - Bundle.java Line 277,297: Do we need two separate iteration loops here? Two iteration loops look like the same. Line 303: typo "paris" Line 606: typo "Someting" Line 728: Could use foreach here. - CLDRConverter.java Line 388: The FormatData bundle is now "OPEN", wh

Re: [8] Code review request: 8000983 and 8003267

Thank you, Okutsu-san. It looks good to me now. Naoto On 12/7/12 8:05 AM, Masayoshi Okutsu wrote: Thank you for your review comments. On 12/7/2012 5:49 AM, Naoto Sato wrote: Here are my comments: - Bundle.java Line 277,297: Do we need two separate iteration loops here? Two iteration loops

[8]Review Request: 7162007: Clean up i18n related caches

Hello, (To build-dev folks, I am sending this to you as the change includes one modification in make directory. It is just simply adding a new Java file, so I think it won't affect the new build-infra structure) Please review the changes for this issue: http://bugs.sun.com/view_bug.do?bug_id

Re: RFR: 8010465: Can't enable sjavac when building in jprt.

Hello, Is anyone looking into this issue (on the jbs, noone is assigned)? This has been biting me as well on Windows builds quite a while. Naoto On 4/8/13 7:11 AM, Alexander Scherbatiy wrote: On 4/8/2013 5:21 PM, Erik Joelsson wrote: On 2013-04-08 15:17, Anthony Petrov wrote: Thanks for

RFR: 8251317: Support for CLDR version 38

Hi, Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change. - Commit messages: - Updated the version in `cldr.md` files - Merge

Re: RFR: 8251317: Support for CLDR version 38

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato wrote: > Hi, > > Please review the changes for upgrading the CLDR data to version 38. The vast > majority of the changes are simply the changes in CLDR upstream, and others > are mainly test changes due to the locale data change.

RFR: 8247432: Update IANA Language Subtag Registry to Version 2020-09-29

Hi, Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK. - Commit messages: - LSR 2020-09-29 - LSR 2020-07-17 Changes: https://git.openjdk.java.net/jdk/pull/1357/files Webrev: https://webrevs.openjdk.

Integrated: 8247432: Update IANA Language Subtag Registry to Version 2020-09-29

On Fri, 20 Nov 2020 17:55:55 GMT, Naoto Sato wrote: > Hi, > > Please review the changes to the subject issue. This is to incorporate the > latest language subtag registry definition into the JDK. This pull request has now been integrated. Changeset: ae0ca743 Author: Nao

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman wrote: >> The mapping and nr tables, and the *-X.java.template files in >> make/data/charsetmapping are used to generate source code for the java.base >> and jdk.charsets modules. The stdcs-$OS files configure the package and >> module that each ch

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by >

Re: RFR: 8253497: Core Libs Terminology Refresh

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words > with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were > changed as follows: > 1

Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Move to share/data, and move jdwp.spec to java.se > > Reviewed changes to `character

Re: RFR: 8263677: Improve Character.isLowerCase/isUpperCase lookups [v2]

On Tue, 16 Mar 2021 21:02:28 GMT, Claes Redestad wrote: >> This patch changes the otherLowercase / otherUppercase bits to be set if >> either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or >> the Unicode Other_Lowercase / Other_Uppercase property is set. This >> simplifies

Re: RFR: 8264779: Fix doclint warnings in java/nio [v2]

On Wed, 7 Apr 2021 14:40:48 GMT, Conor Cleary wrote: >> This fix addresses the following warnings which were generated by building >> JDK API documentation with the `-Xdoclint:all` option enabled: >> >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java

Re: RFR: 8264779: Fix doclint warnings in java/nio [v2]

On Wed, 7 Apr 2021 17:58:58 GMT, Conor Cleary wrote: >> src/java.base/share/classes/java/nio/exceptions line 31: >> >>> 29: PACKAGE=java.nio >>> 30: # This year should only change if the generated source is modified. >>> 31: COPYRIGHT_YEARS="2000, 2021," >> >> Does not seem necessary, as I don'

Re: RFR: 8264779: Fix doclint warnings in java/nio [v2]

On Wed, 7 Apr 2021 18:04:48 GMT, Alan Bateman wrote: >> It could, maybe something like "The length of the input byte (or character) >> sequence." would work? > > or just "The length of the input" so that it is consistent with the > description of the getInputLength method. That sounds good. -

Re: RFR: 8264779: Fix doclint warnings in java/nio [v3]

On Wed, 7 Apr 2021 18:54:26 GMT, Conor Cleary wrote: >> This fix addresses the following warnings which were generated by building >> JDK API documentation with the `-Xdoclint:all` option enabled: >> >> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java

RFR: 8258794: Support for CLDR version 39

Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassi

Re: RFR: 8258794: Support for CLDR version 39

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato wrote: > Please review the changes to support CLDR version 39. The vast majority of > the changes are purely data changes from Unicode. The only change affected in > logic was in `CLDRLocaleProviderAdapter.java`, where it needed to

Integrated: 8258794: Support for CLDR version 39

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato wrote: > Please review the changes to support CLDR version 39. The vast majority of > the changes are purely data changes from Unicode. The only change affected in > logic was in `CLDRLocaleProviderAdapter.java`, where it needed to

RFR: 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter

Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`). - Commit messages: - 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter Changes

Re: RFR: 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter [v2]

> Please review the fix to the tier4 build failure. The piece of code that made > into `CLDRLocaleProviderAdapter.java` was also needed in the build tool > counterpart (`CLDRConverter`). Naoto Sato has updated the pull request incrementally with one additional commit since the last

Integrated: 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter

On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato wrote: > Please review the fix to the tier4 build failure. The piece of code that made > into `CLDRLocaleProviderAdapter.java` was also needed in the build tool > counterpart (`CLDRConverter`). This pull request has now been integrated.

Re: RFR: 8264678: Incomplete comment in build.tools.generatecharacter.GenerateCharacter

On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad wrote: > I'm not exactly sure what I intended to say in this partial comment. Removing > it. Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3766

RFR: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11

Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK. - Commit messages: - Renaming the test case - LSR 2021-05-11 - LSR 2021-03-05 - LSR 2021-02-23 - LSR 2020-12-18 Changes: https://git.openjdk.java.

Integrated: 8258795: Update IANA Language Subtag Registry to Version 2021-05-11

On Wed, 12 May 2021 16:28:54 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. This is to incorporate the > latest language subtag registry definition into the JDK. This pull request has now been integrated. Changeset: a259ab4a Author: Naoto Sato URL:

RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current

Please review the changes to the subject issue. java.util.Locale class has a long-standing issue for those obsolete ISO 639 languages where its normalization ends up in the obsolete codes. This change intends to flip the normalization towards the current codes, providing a system property for c

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28

Re: RFR: JDK-8266254: Update to use jtreg 6

On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the > version of jtreg to use, for those systems that rely on this file. In > addition, the `requiredVersion`

Re: RFR: JDK-8266254: Update to use jtreg 6 [v2]

On Wed, 2 Jun 2021 20:15:55 GMT, Jonathan Gibbons wrote: >> Please review the change to update to using jtreg 6. >> >> The primary change is to the jib-profiles.js file, which specifies the >> version of jtreg to use, for those systems that rely on this file. In >> addition, the `requiredVers

RFR: 8264792: The NumberFormat for locale sq_XK formats price incorrectly.

Please review the fix to the subject issue. The root cause of this problem is that the currency for the country code `XK` is undefined because the country code is user-defined in the ISO 3166 standard. However, it is commonly used to represent the region `Kosovo`, which CLDR supports and subsequ

Integrated: 8264792: The NumberFormat for locale sq_XK formats price incorrectly.

On Fri, 6 Aug 2021 16:39:34 GMT, Naoto Sato wrote: > Please review the fix to the subject issue. The root cause of this problem is > that the currency for the country code `XK` is undefined because the country > code is user-defined in the ISO 3166 standard. However, it is commonly u

Re: RFR: 8272805: Avoid looking up standard charsets [v2]

On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote: >> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120. >> >> In many places standard charsets are looked up via their names, for example: >> absolutePath.getBytes("UTF-8"); >> >> This could be done more efficiently(up t

RFR: 8274658: ISO 4217 Amendment #170 Update

This is to incorporate the ISO 4217 amendment #170, which has been released today, effective immediately. - Commit messages: - 8274658: ISO 4217 Amendment #170 Update Changes: https://git.openjdk.java.net/jdk/pull/5790/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=57

Integrated: 8274658: ISO 4217 Amendment 170 Update

On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment #170, which has been released > today, effective immediately. This pull request has now been integrated. Changeset: f2404d60 Author: Naoto Sato URL: https://git.openjdk.java.n

RFR: 8274407: (tz) Update Timezone Data to 2021c

This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted. The PR also fixes two issues along with the 2021c upgrade. - Commit messages: - Fix for Asia/Amman test case erro

Re: RFR: 8274407: (tz) Update Timezone Data to 2021c

On Wed, 6 Oct 2021 19:43:06 GMT, Sean Coffey wrote: >> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c >> level. Note that the tz data is "as is", as released by IANA. No `merged >> links` are retracted. >> The PR also fixes two issues along with the 2021c upgrade. > >

Integrated: 8274407: (tz) Update Timezone Data to 2021c

On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato wrote: > This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c > level. Note that the tz data is "as is", as released by IANA. No `merged > links` are retracted. > The PR also fixes two issues along wi

Re: RFR: 8275766: (tz) Update Timezone Data to 2021e

On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote: > Please review the integration of tzdata2021e (including tzdata2021d) to the > JDK. > The fix has passed all relevant JTREG regression tests and JCK tests. > > 8275754: (tz) Update Timezone Data to 2021d > 8275849: TestZoneInfo310.java fai

RFR: 8268081: Support for Unicode 14

Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted. - Commit messages: - Amend unicode.md and icu.md files - Minor fixup - Merge branch 'master' into unicode - Copyright year to 2022 - IC

Integrated: 8268081: Upgrade Unicode Data Files to 14.0.0

On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote: > Please review the changes for upgrading the Unicode support in the JDK, from > version 13 to version 14. Corresponding CSR has also been drafted. This pull request has now been integrated. Changeset: 0a094d7c Author: Naoto Sat

RFR: 8176706: Additional Date-Time Formats

Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html - Commit messages: - Removed trailing space - Merge branch 'ma

Re: RFR: 8176706: Additional Date-Time Formats [v2]

> Following the prior discussion [1], here is the PR for the subject > enhancement. CSR has also been updated according to the suggestion. > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html Naoto Sato has updated the pull request increme

Re: RFR: 8176706: Additional Date-Time Formats [v2]

On Tue, 8 Feb 2022 00:39:04 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Modified per suggestions on the PR > > src/java.base/share/classes/java/time/format/DateTimeFor

Re: RFR: 8176706: Additional Date-Time Formats [v2]

On Mon, 7 Feb 2022 21:22:12 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Modified per suggestions on the PR > > src/java.base/share/classes/java/time/format/DateTim

Re: RFR: 8176706: Additional Date-Time Formats [v3]

> Following the prior discussion [1], here is the PR for the subject > enhancement. CSR has also been updated according to the suggestion. > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html Naoto Sato has updated the pull request increme

Re: RFR: 8176706: Additional Date-Time Formats [v4]

> Following the prior discussion [1], here is the PR for the subject > enhancement. CSR has also been updated according to the suggestion. > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html Naoto Sato has updated the pull request increme

Re: RFR: 8176706: Additional Date-Time Formats [v3]

On Thu, 10 Feb 2022 22:20:48 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate > > src/java.base

Re: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame

On Wed, 2 Mar 2022 18:56:40 GMT, Tim Prinzing wrote: > The caller class returned by Reflection::getCallerClass was used to gain > access to it's module in most cases and class loader in one case. I added a > method to translate the caller class to caller module so that the decision of > what m

Re: RFR: 8257733: Move module-specific data from make to respective module [v6]

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFR: 8257733: Move module-specific data from make to respective module [v6]

On Wed, 16 Mar 2022 21:56:53 GMT, Magnus Ihse Bursie wrote: >> make/modules/jdk.charsets/Gensrc.gmk line 32: >> >>> 30: # Generate files using the charsetmapping tool >>> 31: # >>> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping >> >> Is it intentional to leave `java.b

Re: RFR: 8257733: Move module-specific data from make to respective module [v9]

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

RFR: 8283277: ISO 4217 Amendment 171 Update

This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead as JDK19 won't be released by 4/1. - Commit messages: - 8283277: ISO 4217 Amendment 171 Update Changes: https://git.openjdk.jav

Integrated: 8283277: ISO 4217 Amendment 171 Update

On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE > redenomination (removing 3 zeros). Its effective date is 4/1, but I went > ahead as JDK19 won't be released by 4/1. This pull request has now b

RFR: 8265315: Support for CLDR version 41

This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-4

Re: RFR: 8265315: Support for CLDR version 41

On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote: > This is to upgrade the CLDR data from version 39 to version 41 which was > released yesterday. The vast majority of the changes are basically replacing > the CLDR data, along with tools/testcase alignments. Here is the link to CLDR

Re: RFR: 8265315: Support for CLDR version 41 [v2]

unicode.org/index/downloads/cldr-41 Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into cldr+ - Merge branch 'master' into cldr+ - CLDR v41 final - CLDR v41 beta2 - Mer

Integrated: 8265315: Support for CLDR version 41

On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote: > This is to upgrade the CLDR data from version 39 to version 41 which was > released yesterday. The vast majority of the changes are basically replacing > the CLDR data, along with tools/testcase alignments. Here is the link to CLDR

RFR: 8283324: CLDRConverter run time increased by 3x

Fixing performance regression caused by the fix to https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra looping through the resource map multiple times which was not necessary. The execution time of the tool now got back on par with close to JDK18. - Commit me

Integrated: 8283324: CLDRConverter run time increased by 3x

On Mon, 18 Apr 2022 23:16:18 GMT, Naoto Sato wrote: > Fixing performance regression caused by the fix to > https://bugs.openjdk.java.net/browse/JDK-8176706. The fix introduced extra > looping through the resource map multiple times which was not necessary. The > execution time of

RFR: 8286399: Address possibly lossy conversions in JDK Build Tools

Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch. - Commit messages: - 8286399: Address possibly lossy conversions in JDK Build Tools Changes: https://git.openjdk.java.net/jdk/pull/8706/files Webrev: https://webrevs.openjdk.java.net/?repo=jd

Re: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools

On Fri, 13 May 2022 22:11:17 GMT, Joe Wang wrote: >> Applied required casts for the upcoming warning. Verified by cherry-picking >> Adam's patch. > > make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java > line 1278: > >> 1276: state[numCateg

Integrated: 8286399: Address possibly lossy conversions in JDK Build Tools

On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato wrote: > Applied required casts for the upcoming warning. Verified by cherry-picking > Adam's patch. This pull request has now been integrated. Changeset: c044cb83 Author: Naoto Sato URL: https://git.openjdk.java.net

RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter

Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the origin

Re: RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter [v2]

the same as the original ones. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: minor fixup - Changes: - all: https://git.openjdk.java.net/jdk/pull/8887/files - new: https://git.openjdk.java.net/jdk/pull/8887/files/faab3e

Integrated: 8287187: Utilize HashMap.newHashMap() in CLDRConverter

On Wed, 25 May 2022 16:43:59 GMT, Naoto Sato wrote: > Refactoring the leftover self-calculations of the optimized `HashMap` initial > value with `newHashMap()` method. Also replaced some string literals using > text blocks for better readability. Confirmed that the output resour

[11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone

Hello, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8189784 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8189784/webrev.02/ There were two causes of the issue. One was that j.t.f.ZoneName contained hard coded mappings b

Re: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone

indent [1]. In this case I would also advocate breaking the line sooner to make side by side comparisons easier in the future. /Erik [1] http://openjdk.java.net/groups/build/doc/code-conventions.html On 2018-04-09 13:20, Naoto Sato wrote: Hello, Please review the changes to the following

[11] RFR: 8201507: Generate alias entries in j.t.f.ZoneName from tzdb at build time

Hi, Please review the fix to the subject issue. While fixing 8189784 [1], I noticed that not only CLDR zones but also tzdb link entries are also hard coded. So I further modified j.t.f.ZoneName to generate tzdb entries at the build time. The issue: https://bugs.openjdk.java.net/browse/JDK-82

Re: RFR: JDK-8204973: Add build support for filtering translations

Looks good to me. Naoto On 6/14/18 11:52 AM, Erik Joelsson wrote: Hello, Here is a new version of the patch: http://cr.openjdk.java.net/~erikj/8204973/webrev.02/ Changes from last time: * Made the regexp for finding locales more correct. It still does not try to match 3 letter language str

[12]: RFR: Use CLDR's time zone mappings for Windows

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8209167 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8209167/webrev.01/ This fix is to remove the hand crafted map file (lib/tzmappings) on Windows, which maps Windows tim

Re: [12]: RFR: 8209167: Use CLDR's time zone mappings for Windows

h this changeset (it was actually described as a comment in the jira issue). Naoto On 9/12/18 9:08 AM, Erik Joelsson wrote: On 2018-09-12 03:19, Magnus Ihse Bursie wrote: On 2018-09-10 23:34, Naoto Sato wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk

[12] RFR: 8209880: tzdb.dat is not reproducibly built

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8209880 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8209880/webrev.00/ The fix is to remove the use of HashSet/Map which is not guaranteed to preserve the same order on i

Re: RFR: JDK-8218186 Clean up CLDR generation in build

Hi Magnus, I am assuming that the generated resource bundles are exactly the same as before this fix, correct? Naoto On 2/1/19 2:50 AM, Magnus Ihse Bursie wrote: The CLDR data is, since Jigsaw, used in two different modules -- java.base and jdk.localedata. Unfortunately, the split between th

Re: RFR: JDK-8218186 Clean up CLDR generation in build

Thanks, Magnus. The change looks good to me too. Naoto On 2/5/19 1:57 AM, Magnus Ihse Bursie wrote: On 2019-02-01 14:43, [email protected] wrote: Hi Magnus, I am assuming that the generated resource bundles are exactly the same as before this fix, correct? Yes. I have verified this usi

Re: Add a suggestion for non-English locale of Linux in the test doc

As for the wording, I'd suggest "Non-US Locale" instead of "Non-English." Some tests may depend on US customary behavior, such as date format, decimal separator, etc. Naoto On 4/15/19 6:59 AM, Erik Joelsson wrote: Hello, Documenting this is certainly the least we can do. If our tests depend

Re: [13] RFR: 8221431: Support for Unicode 12.1

Adding build-dev, as the change adds a small build tool to parse emoji-data. Naoto On 5/22/19 3:26 PM, [email protected] wrote: Hi, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8221431 The proposed CSR and changeset are located at: https://b

Re: [13] RFR: 8221431: Support for Unicode 12.1

Hi Erik, Thank you for your comments. Updated the webrev accordingly: https://cr.openjdk.java.net/~naoto/8221431/webrev.04/ Naoto On 5/22/19 4:13 PM, Erik Joelsson wrote: Hello Naoto, In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double $$. I would recommend calling the

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

Hi, Please review the fix to the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8212970 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8212970/webrev.09/ This change aims to support the "vanguard" IANA time zone data format, which uses the negative

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

Hi Joe, Thank you for the review. On 7/24/19 2:57 PM, Joe Wang wrote: Hi Naoto, The method findNegativeSavings method in TzdbZoneRulesProvider.java states that it "Find the minimum negative savings". While the result is correct since the rules all have the same value for SAVE, I wonder if t

Re: RFR: JDK-8065704 Set LC_ALL=C for all relevant commands in the build system

Hi Magnus, Looks good to me. Although I cannot provide any reproducible problematic instance, there have been instances where native tools, such as `date` command had produced localized date, and the build failed to parse it in US format. Anyways, it is a good preventive measure to me. Naoto

Re: RFR: JDK-8241463 Move build tools to respective modules

Hi Magnus, I looked at i18n related changes: make/CopyInterimTZDB.gmk make/ToolsJdk.gmk make/gendata/Gendata-java.base.gmk make/gendata/GendataBreakIterator.gmk make/gendata/GendataTZDB.gmk make/gensrc/GensrcCharacterData.gmk make/gensrc/GensrcEmojiData.gmk They look ok to me. The *.java chang

Re: RFR: JDK-8243985 Make source generation by generatecharacter reproducible

Looks good. Naoto On 4/28/20 2:19 AM, Magnus Ihse Bursie wrote: For no really good reason, the generatecharacter buildtool outputs the current time in the generated source. While this has no effect on the generated class files, it makes gensrc comparison fail between builds. Bug: https://bug

Re: RFR [16/java.xml] 8251561: Fix doclint warnings in the java.xml package

+1 Naoto On 8/25/20 11:47 AM, Joe Wang wrote: Cc-ing [email protected] (makefile change: make/Docs.gmk) Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/ Thanks Roger! Please see inline comments. On 8/25/20 8:09 AM, Roger Riggs wrote: Hi Joe, Eliminating th

Re: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar wrote: > Hi Guys, > > Please review the patch for tzdata2020b integration into JDK. > > Release details can be found here: > > https://mm.icann.org/pipermail/tz-announce/2020-October/59.html > > Bug: https://bugs.openjdk.java.ne

Re: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c

On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar wrote: > Hi Guys, > > Please review the integration of tzdata2020c to JDK. > > Details regarding the change can be viewed at - > https://mm.icann.org/pipermail/tz-announce/2020-October/60.html > Bug: https://bugs.openjdk.java.net

Re: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c [v2]

On Tue, 20 Oct 2020 11:39:36 GMT, Kiran Sidhartha Ravikumar wrote: >> Hi Guys, >> >> Please review the integration of tzdata2020c to JDK. >> >> Details regarding the change can be viewed at - >> https://mm.icann.org/pipermail/tz-announce/2020-October/60.html >> Bug: https://bugs.openjdk.j

RFR: 8247781: Day periods support

Hi, Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR: https://bugs.

Re: RFR: 8247781: Day periods support [v2]

otivation and its spec are in this CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254629 > > Naoto Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressed the following comments: - https://github.com/openjdk/jdk/pul

  1   2   >