JEP 421. It also updates the relevant @SuppressWarning annotations.
>
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).
Brent Christian has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 34 commits:
JEP 421. It also updates the relevant @SuppressWarning annotations.
>
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).
Brent Christian has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 33 commits:
JEP 421. It also updates the relevant @SuppressWarning annotations.
>
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).
Brent Christian has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 32 commits:
On Fri, 19 Nov 2021 18:06:39 GMT, Mandy Chung wrote:
>> Here are the code changes for the "Deprecate finalizers in the standard Java
>> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
>> review.
>>
>> This change makes the indicated deprecations, and updates the API spe
Here are the code changes for the "Deprecate finalizers in the standard Java
API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
This change makes the indicated deprecations, and updates the API spec for JEP
421. It also updates the relevant @SuppressWarning annotatio
On Wed, 18 Aug 2021 18:35:53 GMT, Ian Graves wrote:
>> 8271302: Regex Test Refresh
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Couple of fixes
Marked as reviewed by bchristi (Reviewer).
-
PR: https://git.op
On Wed, 11 Aug 2021 18:22:42 GMT, Ian Graves wrote:
> 8271302: Regex Test Refresh
Changes requested by bchristi (Reviewer).
In the JBS issue, it looks like the Description was put in the Environment. :)
test/jdk/java/util/regex/RegExTest.java line 291:
> 289:
> 290: int resultStart1
On Wed, 10 Mar 2021 02:31:28 GMT, Ian Graves wrote:
>> This fixes a zero-adding issue observed in the hex float conversion.
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updating Formatter copyright date
Marked as reviewed
On Mon, 8 Mar 2021 21:25:32 GMT, Ian Graves wrote:
> This fixes a zero-adding issue observed in the hex float conversion.
This all looks fine - just update the copyright year in Formatter.java, please.
In my personal opinion, this behavior change does not rise to the level of
needing a CSR, bu
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
> cha
. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Brent Chr
On Wed, 16 Dec 2020 07:10:41 GMT, Alan Bateman wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> improve SERIAL_FILTER_PATTERN comment
>
> src/java.base/share/classes/java/util/Loc
. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Brent Chr
On Tue, 15 Dec 2020 22:13:58 GMT, Stuart Marks wrote:
>> It's an adverb, since it's the act of 'defining' that is being done too
>> restrictively or broadly. If you want to have an adjective you would need to
>> rephrase it so it applies to the noun, like 'defining a too restrictive
>> accept-
. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Brent Chr
On Tue, 15 Dec 2020 22:02:00 GMT, Lance Andersen wrote:
>> test/jdk/java/lang/ClassLoader/Assert.java line 65:
>>
>>> 63:
>>> 64: int switchSource = 0;
>>> 65: if (args.length == 0) { // This is the coordinator version
>>
>> Perhaps s/coordinator/controller/?
>
> Let's change i
On Tue, 15 Dec 2020 07:32:12 GMT, Alan Bateman wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updates, per code review
>
> test/jdk/java/nio/channels/SocketChannel/CloseRegistered
. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Brent Chr
On Mon, 14 Dec 2020 21:08:35 GMT, Joe Wang 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.
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. grandfathered -> legacy
2. blacklist -> filter or reject
3. whitelist
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.
Changes seem fine
On Fri, 23 Oct 2020 16:48:03 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this small exception message fix.
>
> Naoto
Looks good.
-
Marked as reviewed by bchristi (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/841
On Wed, 21 Oct 2020 23:16:15 GMT, Naoto Sato wrote:
>> Hi, Naoto
>>
>> What is the source for the updated values in LocaleNames.properties?
>>
>> Also, could the bug synopsis be updated to be more descriptive?
>>
>> Thanks,
>> -Brent
>
> Hi Brent,
>
>> What is the source for the updated value
On Wed, 21 Oct 2020 23:38:23 GMT, Naoto Sato wrote:
>> Hi,
>>
>> Please review the changes to the subject issue. The fix replaces the
>> obsolete/incorrect English language/region/script display names in the
>> COMPAT root locale bundle. The data are derived from CLDR's English names.
>
> Naot
On Wed, 21 Oct 2020 20:39:18 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes to the subject issue. The fix replaces the
> obsolete/incorrect English language/region/script display names in the COMPAT
> root locale bundle. The data are derived from CLDR's English names.
Hi, Naoto
W
Hi, Naoto
The latest changes look good to me.
-Brent
On 7/22/20 10:23 AM, naoto.s...@oracle.com wrote:
Hi,
I revised the fix again, based on further suggestions:
https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
Changes from v.04 are (all in StringUTF16.java):
- The short cut n
Hi, Naoto
I have a few comments:
src/java.base/share/classes/java/lang/StringUTF16.java
379 private static int getSupplementaryCodePoint(byte[] ba, int cp,
int index, int start, int end)
I think it would be worth a small addition to the comment to reflect
that non-surrogate chars are re
Looks good. -B
On 11/6/19 6:11 PM, naoto.s...@oracle.com wrote:
Here is the updated webrev:
https://cr.openjdk.java.net/~naoto/8232871/webrev.01/
Hi, Naoto
Looks pretty good. I have a few comments:
--
src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
572 map = new HashMap<>();
FWIW, I believe the HashMap could be pre-sized using 'names.length'.
--
src/java.base/macosx/native
Thanks. Looks good to me.
-Brent
On 5/21/19 11:33 AM, naoto.s...@oracle.com wrote:
Thanks, Brent. Modified the webrev accordingly:
http://cr.openjdk.java.net/~naoto/8224105/webrev.01/
Naoto
On 5/21/19 11:03 AM, Brent Christian wrote:
Hi, Naoto. I have a couple comments.
src/java.base
Hi, Naoto. I have a couple comments.
src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
String.isEmpty() could be used in place of equals("").
test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java
Maybe give the new constants names in all-caps.
Thanks, Naoto. An automated test run looked fine, so I've pushed this
change.
-Brent
On 10/12/17 12:38 PM, Naoto Sato wrote:
Looks fine, Brent.
Naoto
On 10/12/17 11:52 AM, Brent Christian wrote:
Hi,
Please review my change to prevent a startup crash on earlier versions
of
Hi,
Please review my change to prevent a startup crash on earlier versions
of MacOS.
Bug: https://bugs.openjdk.java.net/browse/JDK-8187772
Webrev: http://cr.openjdk.java.net/~bchristi/8187772/webrev.00/
When a non-default currency is set in the Language & Region control
panel, it's reflec
The fix looks good, Naoto.
Thanks,
-Brent
On 7/18/17 3:23 PM, Naoto Sato wrote:
Hello,
Please review this small fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8183902
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8183902/webrev.00/
This is a leftov
Thanks, Naoto. The updated changes look good.
-Brent
On 06/28/2017 03:13 PM, Naoto Sato wrote:
Thanks, Brent! Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8160199/webrev.04/
And my comments embedded below:
On 6/28/17 2:16 PM, Brent Christian wrote:
Hi, Naoto
This looks
Hi, Naoto
This looks quite good.
I will test a bit with some of the trickier locales. BTW, the script
will now also be reflected in Locale.getScript() and
Locale.getDisplayScript().
Just a few comments:
---
src/java.base/macosx/native/libjava/java_props_macosx.h
Update copyright year
---
Hi, Naoto
On 4/5/17 2:14 PM, Naoto Sato wrote:
I revised the test case not to rely on shell script.
Yay! Hopefully this can also happen sometime for JDK 9+.
http://cr.openjdk.java.net/~naoto/816/webrev.01/
Looks fine to me, Naoto. A few comments:
* I presume additional @bug values w
Hi, Naoto
That fix looks fine.
The "Portuguese (Brazil)" fix now happens before the Language ID fix,
but that shouldn't matter, as the "pt_BR" ID won't trigger that code
anyway (doesn't contain '-').
One very mall nit I noticed: one more space on line 97 will realign it
with line 96, which
Looks good to me, Naoto.
-Brent
On 02/14/2017 11:05 AM, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8174779
The proposed fix is located at:
http://cr.openjdk.java.net/~naoto/8174779/webrev.01/
The root cause of the problem
e default switch
case when we call CFLocaleGetIdentifier(), which I guess was the source
of my confusion.
I've removed that comment line, and reworked the comment a little bit.
http://cr.openjdk.java.net/~bchristi/7131356/webrev.05/
Thanks,
-Brent
On 6/23/16 8:24 AM, Naoto Sato wrote:
On 6/22/16
On 6/23/16 8:24 AM, Naoto Sato wrote:
On 6/22/16 9:48 PM, Brent Christian wrote:
On 6/22/16 3:58 PM, Naoto Sato wrote:
2. I think mapping language/script combination to a typical locale is ok
to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS,
right?
the meantime, I would like to have "user.script" set to
"Latn" in such a case.
Is this something that I could file a follow-on issue for? The existing
code doesn't set "user.script" in these cases, either, and it looks like
that would take some digging into
On 22/06/16 15:10, Alex Strange wrote:
On Jun 20, 2016, at 3:44 PM, Brent Christian wrote:
I'd prefer something that can build on SDK 10.9 and 10.10, etc.
There might be a way to #ifdef it out (not sure), but it's not worth it.
I came to the same conclusion. :)
Thanks!
-Brent
old.txt
2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt
On 6/21/16 3:17 PM, Brent Christian wrote:
Hi, Naoto
"Spanish (Latin America)" already works the same as it did before the
change - it maps to "es_XL". Because "es-419" has more than 2
cha
nt,
I looked at the system preference setting panel and noticed there is
"Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as
the designate region. Can you make changes to deal with it? (sorry I
should have noticed this earlier, and it's unfortunate not to
Hi,
I have an updated webrev at:
http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
The comments have been updated as Gerard suggested.
The code to process the languageString now accounts for 3-character
language codes, and 4-char script designations (line 86).
More extensive testing of
Alex - thanks for your response. More below...
On 6/13/16 4:51 PM, Alex Strange wrote:
2. In "setupMacOSXLocale" we simply drop the call to
"JRSSetDefaultLocalization" as it appears to be a NOP. According to
Apple, that API sets up native bundle locale, so that any access to
native Cocoa UI (l
On 6/13/16 5:14 PM, Naoto Sato wrote:
On 13/06/2016 16:20, Brent Christian wrote:
Following the call to
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
the language to a default country
So does this mean the new code will not honor the "Region" in the OS
On 6/13/16 4:20 PM, Brent Christian wrote:
On 13/06/2016 14:43, Naoto Sato wrote:
Also, the array index "2" to assume the language length is 2 is not
correct, as there are three letter language codes. So the code should
literally look for "-" instead.
Great, thanks. I
Hi,
Please review this Mac-only fix:
http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-7131356
Thanks go to Gerard Ziemski for the thorough investigation and detailed
write-up in the bug report.
The symptoms:
On those OS X machines where the de
Hi, Naoto. Thank you for having a look.
On 13/06/2016 14:43, Naoto Sato wrote:
On 6/13/16 1:58 PM, Brent Christian wrote:
The original Apple code then calls into
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
"language_REGION" (ex. "
51 matches
Mail list logo
