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
on) 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
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
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/jdk/
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:
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:
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
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
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
de.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
- Merge branch 'master' into c
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
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:
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 been i
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:
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
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
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
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
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
> 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
> 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
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
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
> 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
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
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
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
-
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
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
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.
>
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
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
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:
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
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 comm
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
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
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`
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.
>
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
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:
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:
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
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.
> 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
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
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 neede
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 neede
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
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:
>>
>>
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.
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
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:
>>
>>
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
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
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:
>
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
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
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
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:
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 chan
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
-
On Tue, 3 Nov 2020 00:00:26 GMT, Kiran Sidhartha Ravikumar
wrote:
>> My question is why it is failing. Have you figured it? The existing
>> exceptions are either negative DST or last rule beyond 2037, which javazic
>> cannot handle. The changes introduced with 2020d does not meet either of
On Mon, 2 Nov 2020 18:06:28 GMT, Kiran Sidhartha Ravikumar
wrote:
>> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:
>>
>>> 199: zid.equals("Iran") || // last rule mismatch
>>> 200: zid.equals("Asia/Gaza") || // last rule mismatch
>>> 201:
On Mon, 2 Nov 2020 16:29:07 GMT, Kiran Sidhartha Ravikumar
wrote:
> Hi Guys,
>
> Please review the integration of tzdata2020d to JDK.
>
> Details regarding the change can be viewed at -
> https://mm.icann.org/pipermail/tz-announce/2020-October/62.html
> Bug:
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:
Fixed exception messages.
-
Changes:
- all: https://git.openjdk.ja
On Fri, 30 Oct 2020 10:33:28 GMT, Stephen Colebourne
wrote:
>> 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/
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/pull/938#disc
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:
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:
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:
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:
+1
Naoto
On 8/25/20 11:47 AM, Joe Wang wrote:
Cc-ing build-dev@openjdk.java.net (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
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:
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
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.
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
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
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
Adding build-dev, as the change adds a small build tool to parse emoji-data.
Naoto
On 5/22/19 3:26 PM, naoto.s...@oracle.com 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:
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
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, naoto.s...@oracle.com 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
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
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
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.java.net/
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
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
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:
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
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
Looks good to me.
Naoto
On 7/19/17 10:33 PM, Nishit Jain wrote:
Hi,
Please review the fix for JDK-8177472
Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
Issue:The existing process of updating the LSR data requires manual
Hi Mandy,
Just noticed that the CLDR license is located under jdk.localedata
module. That needs to be moved into java.base, as its English resource
files are derived from CLDR too.
Naoto
On 12/7/16 1:28 PM, Mandy Chung wrote:
This proposes to organize license files by module in source,
Looks good to me.
Naoto
On 10/20/16 1:33 AM, Masayoshi Okutsu wrote:
Hi,
Please review the changes for JDK-8165804 which is a follow-up of
JDK-8076757. Some notes on the changes.
- Removed INCLUDES := $(TEXT_PKG_LD) from
make/gendata/GendataBreakIterator.gmk in order to avoid compiling
Thanks for the review Tim!
On 7/20/16 5:40 PM, Tim Bell wrote:
Naoto:
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8160873
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8160873/webrev.01/
The gist of the issue is that those
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8160873
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8160873/webrev.01/
The gist of the issue is that those tools used to generate sources at
build time were affected by the
Hi Bob, Alan,
On 10/16/15 8:11 AM, Bob Vandette wrote:
I've skimmed through the patches and the DEF_* macros look okay. The only one
that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then
I think the include of jni_util.h needs to move from jawt.h to jawt.c.
Ok, I’ll
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 to CLDR Locale data in JDK 9 b71 causes SimpleDateFormat
parsing errors
+1
Naoto
On 6/30/15 12:49 AM, Erik Joelsson wrote:
Hello,
Please review this small patch which fixes the incremental build of
java.base-gensrc. There is a slight mistake in
jdk/make/gensrc/GensrcCLDR.gmk where the target file of a rule has the
wrong path, so make will always think it needs to
is not modified
after its initialization.
Otherwise, the changes look good to me.
Masayoshi
On 6/24/2015 6:56 AM, Naoto Sato wrote:
Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8008577/webrev.01/
As to the 3rd comment below, I did not modify it because that would
simply duplicate
/9/2015 5:58 AM, Naoto Sato wrote:
Hello,
Please review the proposed changes for 8008577[1], the implementation
of the JEP-252[2]. The proposed changes are located at:
http://cr.openjdk.java.net/~naoto/8008577/webrev.00/
Here are the very high level summary of changes:
- Now the default locale
1 - 100 of 153 matches
Mail list logo
