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:
https://bugs.openjdk.java.net/browse/JDK-8159
Looks okay.
Mandy
> On Jun 20, 2016, at 3:00 PM, Naoto Sato wrote:
>
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8159781/webrev.01/
>
> Naoto
>
> On 6/20/16 8:18 AM, Naoto Sato wrote:
>> Hi Mandy, thank you for the review.
>>
>> INCLUDE_LOCALE_FILES is actually a patt
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 p
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
Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8159781/webrev.01/
Naoto
On 6/20/16 8:18 AM, Naoto Sato wrote:
Hi Mandy, thank you for the review.
INCLUDE_LOCALE_FILES is actually a pattern template, and the real filter
patterns are constructed at the runtime with the passed arg
Good! Wasn't aware there is "British English" in the language selection.
Looks like all is working as expected.
Naoto
On 6/20/16 2:34 PM, Brent Christian wrote:
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 Par
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 OSX's
system prefer
Hi Mandy, thank you for the review.
INCLUDE_LOCALE_FILES is actually a pattern template, and the real filter
patterns are constructed at the runtime with the passed argument, by
replacing "%%" with locale patterns. So I think it is less complex to
handle it as the current way.
I will modify