From ramanand.patil at oracle.com  Tue Feb  2 11:00:06 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 2 Feb 2016 03:00:06 -0800 (PST)
Subject: <i18n dev> RFR: 8148446: (tz) Support tzdata2016a
In-Reply-To: <3683f81e-a349-4dbe-8bee-780a0e454fd2@default>
References: <3683f81e-a349-4dbe-8bee-780a0e454fd2@default>
Message-ID: <7050b3f7-d566-4097-bdcc-9cbf76c272e4@default>

HI all,

Please review the latest TZDATA integration (tzdata2016a) to JDK9.

Bug  - https://bugs.openjdk.java.net/browse/JDK-8148446

Webrev - http://cr.openjdk.java.net/~rpatil/8148446/webrev.00/

 

All the TimeZone related tests are passed after integration.

 

Regards,

Ramanand.

From xueming.shen at oracle.com  Tue Feb  2 21:25:23 2016
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 02 Feb 2016 13:25:23 -0800
Subject: <i18n dev> RFR JDK-7071819: To support Extended Grapheme Clusters
	in Regex
In-Reply-To: <569DEB35.7020006@oracle.com>
References: <569DEB35.7020006@oracle.com>
Message-ID: <56B11EC3.3010505@oracle.com>

Hi,

Have not heard any feedback on this one so far. I'm adding
a little more to make it attractive for reviewers :-)

On top of the \N now the webrev includes the proposal to add
two more matchers, \X for unicode extended grapheme cluster
and \b{g} for the corresponding boundary.

Issue: https://bugs.openjdk.java.net/browse/JDK-7071819
Issue: https://bugs.openjdk.java.net/browse/JDK-8147531
webrev: http://cr.openjdk.java.net/~sherman/8147531_7071819/webrev/

Thanks!
Sherman

On 01/18/2016 11:52 PM, Xueming Shen wrote:
> Hi,
>
> Please help review the change to add \N support in regex.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8147531
> webrev: http://cr.openjdk.java.net/~sherman/8147531/webrev
>
> This is one of the items we were planning to address via JEP111
> http://openjdk.java.net/jeps/111
> https://bugs.openjdk.java.net/browse/JDK-8046101
>
> Some of the constructs had been added already in early release. I'm
> planning to address the rest as individual rfe separately.
>
> Thanks,
> Sherman


From xueming.shen at oracle.com  Wed Feb  3 17:09:39 2016
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 3 Feb 2016 09:09:39 -0800
Subject: <i18n dev> RFR JDK-7071819: To support Extended Grapheme
	Clusters in Regex
In-Reply-To: <56B1E3EC.2060509@gmail.com>
References: <569DEB35.7020006@oracle.com> <56B11EC3.3010505@oracle.com>
	<56B1DF63.2040708@gmail.com> <56B1E3EC.2060509@gmail.com>
Message-ID: <56B23453.8020403@oracle.com>

Hi Peter,

Thanks for the review and suggestion.

This appears to be a better approach. I was wondering if I should go 
this way to cache
those lookup tables as well, but ...

Webrev has been updated as suggested.

Thanks!
Sherman

On 2/3/16 3:26 AM, Peter Levart wrote:
> Hi Again,
>
> I also have a comment on the implementation of the hash table and it's 
> GC-ness. You keep the string pool under a SoftReference because it is 
> the biggest object so it makes most sense to clear it when heap 
> becomes full. Other arrays are kept strongly reachable, but you 
> re-generate them nevertheless when string pool is cleared by GC. Would 
> it make sense to:
>
> - define all int[] arrays (including strPool) as final instance 
> variables of CharacterName
> - have one static field:
>
> private static SoftReference<CharacterName> refInstance;
>
> - convert initNamePool() into a private constructor.
>
> - convert public static getName/getCodePoint into public instance methods
>
> - introduce public static method:
>
> public static CharacterName getInstance() {
>     SoftReference<CharacterName> ref = refInstance;
>     CharacterName instance;
>     if (ref != null && ((instance = ref.get) != null) {
>         return instance;
>     }
>     instance = new CharacterName();
>     refInstance = new SoftReference<>(instance);
>     return instance;
> }
>
> ...in this arrangement, you don't need volatile fields or explicit 
> fences, as all instance fields can be final and JMM guarantees safe 
> publication in this case.
>
>
> Regards, Peter
>
> On 02/03/2016 12:07 PM, Peter Levart wrote:
>> Hi Sherman,
>>
>> I don't currently have any idea how to squeeze the hashtable any more 
>> further. It is already very compact in my opinion. But I noticed a 
>> data race that could result in navigating the half-initialized data 
>> structure. It is a classical unsafe publication bug. It has been 
>> present before in get(int cp) and it is present now in both 
>> getName(int cp) and getCodePoint(String name). For example:
>>
>>  151     static int getCodePoint(String name) {
>>  152         byte[] strPool = null;
>>  153         if (refStrPool == null || (strPool = refStrPool.get()) 
>> == null) {
>>  154             strPool = initNamePool();
>>  155         }
>>
>> vs.
>>
>> 111             refStrPool = new SoftReference<>(strPool);
>>
>> ...the static refStrPool field is not marked volatile.
>>
>> One way to fix this is to mark field volatile and then rearrange code 
>> in getName/getCodePoint to only read from it once by introducing a 
>> local var. The other would be to change the line 111 into something like:
>>
>> SoftReference<byte[]> rsp = new SoftReference<>(strPool);
>> unsafe.storeFence();
>> refStrPool = rsp;
>>
>> ...*and* also rearrange code in getName/getCodePoint to only read 
>> from field once by introducing a local var.
>>
>>
>> Regards, Peter
>>
>> On 02/02/2016 10:25 PM, Xueming Shen wrote:
>>> Hi,
>>>
>>> Have not heard any feedback on this one so far. I'm adding
>>> a little more to make it attractive for reviewers :-)
>>>
>>> On top of the \N now the webrev includes the proposal to add
>>> two more matchers, \X for unicode extended grapheme cluster
>>> and \b{g} for the corresponding boundary.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-7071819
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8147531
>>> webrev: http://cr.openjdk.java.net/~sherman/8147531_7071819/webrev/
>>>
>>> Thanks!
>>> Sherman
>>>
>>> On 01/18/2016 11:52 PM, Xueming Shen wrote:
>>>> Hi,
>>>>
>>>> Please help review the change to add \N support in regex.
>>>>
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8147531
>>>> webrev: http://cr.openjdk.java.net/~sherman/8147531/webrev
>>>>
>>>> This is one of the items we were planning to address via JEP111
>>>> http://openjdk.java.net/jeps/111
>>>> https://bugs.openjdk.java.net/browse/JDK-8046101
>>>>
>>>> Some of the constructs had been added already in early release. I'm
>>>> planning to address the rest as individual rfe separately.
>>>>
>>>> Thanks,
>>>> Sherman
>>>
>>
>


From masayoshi.okutsu at oracle.com  Thu Feb  4 06:47:01 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 4 Feb 2016 15:47:01 +0900
Subject: <i18n dev> RFR: 8148446: (tz) Support tzdata2016a
In-Reply-To: <7050b3f7-d566-4097-bdcc-9cbf76c272e4@default>
References: <3683f81e-a349-4dbe-8bee-780a0e454fd2@default>
	<7050b3f7-d566-4097-bdcc-9cbf76c272e4@default>
Message-ID: <56B2F3E5.1070703@oracle.com>

Hi Ramanand,

I noticed that the zones in Yakutsk Time [1] seem to have their own 
names, such as "Khandyga Time" for Asia/Khandyga, and you seem to follow 
that convention for Asia/Chita. That causes some mismatch between the 
long names and abbreviations.

I dag out some past tzdata fixes to see how that happened. What I found 
out is that the 2013b fix [2] used "Yakutsk Time", but that the 2013c 
[3] fix used "Khandyga Time". 2013b went to JDK 7 updates and earlier 
ones and 2013c went to 8. JDK 9 inherits the 8 fix.

I prefer to restore the 2013b convention for Asia/Yakutsk, Asia/Chita, 
and Asia/Khandyga to have:

     {"Yakutsk Time", "YAKT",
      "Yakutsk Summer Time", "YAKST",
      "Yakutsk Time", "YAKT"}

Thanks,
Masayoshi

[1] https://en.wikipedia.org/wiki/Yakutsk_Time
[2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b8009df64dc8
[3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ae35fdbab949

On 2/2/2016 8:00 PM, Ramanand Patil wrote:
> HI all,
>
> Please review the latest TZDATA integration (tzdata2016a) to JDK9.
>
> Bug  - https://bugs.openjdk.java.net/browse/JDK-8148446
>
> Webrev - http://cr.openjdk.java.net/~rpatil/8148446/webrev.00/
>
>   
>
> All the TimeZone related tests are passed after integration.
>
>   
>
> Regards,
>
> Ramanand.


From ramanand.patil at oracle.com  Thu Feb  4 08:55:06 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Thu, 4 Feb 2016 00:55:06 -0800 (PST)
Subject: <i18n dev> RFR: 8148446: (tz) Support tzdata2016a
In-Reply-To: <56B2F3E5.1070703@oracle.com>
References: <3683f81e-a349-4dbe-8bee-780a0e454fd2@default>
	<7050b3f7-d566-4097-bdcc-9cbf76c272e4@default>
	<56B2F3E5.1070703@oracle.com>
Message-ID: <eb949478-9f15-4511-8c63-96cf27b86c5a@default>

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
To: Ramanand Patil; i18n-dev at openjdk.java.net
Cc: core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8148446: (tz) Support tzdata2016a

Hi Ramanand,

I noticed that the zones in Yakutsk Time [1] seem to have their own names, such as "Khandyga Time" for Asia/Khandyga, and you seem to follow that convention for Asia/Chita. That causes some mismatch between the long names and abbreviations.

I dag out some past tzdata fixes to see how that happened. What I found out is that the 2013b fix [2] used "Yakutsk Time", but that the 2013c [3] fix used "Khandyga Time". 2013b went to JDK 7 updates and earlier ones and 2013c went to 8. JDK 9 inherits the 8 fix.

I prefer to restore the 2013b convention for Asia/Yakutsk, Asia/Chita, and Asia/Khandyga to have:

     {"Yakutsk Time", "YAKT",
      "Yakutsk Summer Time", "YAKST",
      "Yakutsk Time", "YAKT"}

Thanks,
Masayoshi

[1] https://en.wikipedia.org/wiki/Yakutsk_Time
[2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b8009df64dc8
[3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ae35fdbab949

On 2/2/2016 8:00 PM, Ramanand Patil wrote:
> HI all,
>
> Please review the latest TZDATA integration (tzdata2016a) to JDK9.
>
> Bug  - https://bugs.openjdk.java.net/browse/JDK-8148446
>
> Webrev - http://cr.openjdk.java.net/~rpatil/8148446/webrev.00/
>
>   
>
> All the TimeZone related tests are passed after integration.
>
>   
>
> Regards,
>
> Ramanand.


From masayoshi.okutsu at oracle.com  Sun Feb  7 22:59:55 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 8 Feb 2016 07:59:55 +0900
Subject: <i18n dev> RFR: 8148446: (tz) Support tzdata2016a
In-Reply-To: <eb949478-9f15-4511-8c63-96cf27b86c5a@default>
References: <3683f81e-a349-4dbe-8bee-780a0e454fd2@default>
	<7050b3f7-d566-4097-bdcc-9cbf76c272e4@default>
	<56B2F3E5.1070703@oracle.com>
	<eb949478-9f15-4511-8c63-96cf27b86c5a@default>
Message-ID: <56B7CC6B.6030800@oracle.com>

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
> To: Ramanand Patil; i18n-dev at openjdk.java.net
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8148446: (tz) Support tzdata2016a
>
> Hi Ramanand,
>
> I noticed that the zones in Yakutsk Time [1] seem to have their own names, such as "Khandyga Time" for Asia/Khandyga, and you seem to follow that convention for Asia/Chita. That causes some mismatch between the long names and abbreviations.
>
> I dag out some past tzdata fixes to see how that happened. What I found out is that the 2013b fix [2] used "Yakutsk Time", but that the 2013c [3] fix used "Khandyga Time". 2013b went to JDK 7 updates and earlier ones and 2013c went to 8. JDK 9 inherits the 8 fix.
>
> I prefer to restore the 2013b convention for Asia/Yakutsk, Asia/Chita, and Asia/Khandyga to have:
>
>       {"Yakutsk Time", "YAKT",
>        "Yakutsk Summer Time", "YAKST",
>        "Yakutsk Time", "YAKT"}
>
> Thanks,
> Masayoshi
>
> [1] https://en.wikipedia.org/wiki/Yakutsk_Time
> [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b8009df64dc8
> [3] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ae35fdbab949
>
> On 2/2/2016 8:00 PM, Ramanand Patil wrote:
>> HI all,
>>
>> Please review the latest TZDATA integration (tzdata2016a) to JDK9.
>>
>> Bug  - https://bugs.openjdk.java.net/browse/JDK-8148446
>>
>> Webrev - http://cr.openjdk.java.net/~rpatil/8148446/webrev.00/
>>
>>    
>>
>> All the TimeZone related tests are passed after integration.
>>
>>    
>>
>> Regards,
>>
>> Ramanand.


From nishit.jain at oracle.com  Mon Feb 15 12:08:22 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 15 Feb 2016 17:38:22 +0530
Subject: <i18n dev> Review Request for JDK-8074411: Describe "minor unit"
 and/or "default fraction digits" in Currency class' javadoc clearly
Message-ID: <56C1BFB6.4080805@oracle.com>

Hello All,

Please review the following fix in "/Currency.java/".

Bug: https://bugs.openjdk.java.net/browse/JDK-8074411
Webrev: http://cr.openjdk.java.net/~rgoel/Nishit/8074411/ 
<http://cr.openjdk.java.net/%7Ergoel/Nishit/8074411/>

Fix: A clarification about "minor units" and "default number of fraction 
digits" is added in the specification. A suggestion to use BigDecimal 
class while working with Currency or monetary values is also added.

Regards,
Nishit Jain

From dmitry.markov at oracle.com  Wed Feb 17 13:01:41 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Wed, 17 Feb 2016 16:01:41 +0300
Subject: <i18n dev> [OpenJDK 2D-Dev] [9] Review request for 8073400:
 Some Monospaced logical fonts have a different width
In-Reply-To: <56BB9CAC.3050408@oracle.com>
References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com>
Message-ID: <56C46F35.6030107@oracle.com>

Hello Phil,

Thank you for the review.

According to unicode table the characters u201c and u201d are in General 
Punctuation block, see 
http://unicode-table.com/en/blocks/general-punctuation/
Many characters from this block are not supported by Courier New. So I 
do not think we need to remove the whole block from the exclusion range, 
since it will not have any effect except few characters like u201c and 
u201d. That's why I removed such small characters set (u2018 - u201F) 
from the exclusion range, but I can change this if it is necessary.

At the same time the characters set (u2018 - u201F) is supported by 
Arial and Times New Roman which are mapped to other logical fonts. The 
adjusted exclusion range seems 'quite safe' from this point of view. So 
I do not think we need to modify any code such as FontConfiguration 
class and so on to apply these changes only to monospaced fonts. Please 
correct me if I am wrong.

Adding i18n-dev.

Internationalization team,
Could you review a small change in windows.fontconfig.properties, please?

     bug: https://bugs.openjdk.java.net/browse/JDK-8073400
     webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/

Problem description:
On Windows some characters (in particular, left and right double 
quotation marks) have width differing from other characters' widths, 
when Monospaced logical font is used.
The default monospaced font for windows platform is Courier New. It 
contains the desired characters, (i.e. '\u201c' and '\u201d'). However 
the characters are in 'exclusion ranges' for this font due to settings 
in windows.fontconfig.properties. So when we try to obtain glyphs for 
these characters and calculate their bounds, we fallback to another font 
(Lucida) and use its glyphs.

Fix:
Remove the following set of characters u2018 - u201F from the exclusion 
ranges.

Thank you in advance,
Dmitry
On 10/02/2016 23:25, Phil Race wrote:
> I expect the exclusion range is there for a reason.
> I think (guess) that the intent was that where there is a sequence 
> like this :
>
> sequence.sansserif.x-windows-950=alphabetic,chinese-ms950,dingbats,symbol,chinese-ms950-extb 
>
>
> then those code points should come from the chinese font.
>
> Perhaps your adjusted exclusion range should apply only to the 
> monospaced fonts
> which are already putting the locale font first.
>
> Unfortunately it doesn't appear that this is possible with the 
> supported syntax
> https://docs.oracle.com/javase/1.5.0/docs/guide/intl/fontconfig.html#windows 
>
>
> i.e it supports selection only by charactersubsetname, not also by 
> logicalfontname.
> But you should check the code to see if this is in fact the case.
> There may need to be a non-ideal decision or a revision to that spec. 
> and its
> supporting code.
>
> And why be so narrow ? It seems you have made an even odder situation
> in having just those two code points 'un'-excluded.
> The argument that those were the two a customer complained about does not
> hold up very well.
>
> I think you should also run this whole change+discussion by i18n-dev ..
>
>
> -phil.
>
> On 01/14/2016 02:32 AM, dmitry markov wrote:
>> Hello,
>>
>> Could you review the fix for jdk9, please?
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8073400
>>     webrev: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.00/
>>
>> Problem description:
>> On Windows some characters (in particular, left and right double 
>> quotation marks) have width differing from other characters' widths, 
>> when Monospaced logical font is used.
>> The default monospaced font for windows platform is Courier New. It 
>> contains the desired characters, (i.e. '\u201c' and '\u201d'). 
>> However the characters are in 'exclusion ranges' for this font due to 
>> settings in windows.fontconfig.properties. So when we try to obtain 
>> glyphs for these characters and calculate their bounds, we fallback 
>> to another font (Lucida) and use its glyphs.
>>
>> Fix:
>> Remove the following set of characters u2018 - u201F from the 
>> exclusion ranges.
>>
>> Thanks,
>> Dmitry
>


From naoto.sato at oracle.com  Wed Feb 17 21:28:03 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 17 Feb 2016 13:28:03 -0800
Subject: <i18n dev> [9] RFR: 8148346: Reduce number of packages in
	jdk.localedata module
Message-ID: <56C4E5E3.1000204@oracle.com>

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8148346

The proposed change is located at:

http://cr.openjdk.java.net/~naoto/8148346/webrev.00/

Vast majority of the changes are changing package names. They used to be 
lang/ctry structure, which bloats the number of locale data package 
names to hundreds. Now it comes down to 8 packages with this fix.

Naoto

From Alan.Bateman at oracle.com  Thu Feb 18 07:07:18 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Feb 2016 07:07:18 +0000
Subject: <i18n dev> [9] RFR: 8148346: Reduce number of packages in
 jdk.localedata module
In-Reply-To: <56C4E5E3.1000204@oracle.com>
References: <56C4E5E3.1000204@oracle.com>
Message-ID: <56C56DA6.7070602@oracle.com>


Naoto - I don't know if this is hg version or webrev related but the 
moves aren't showing up correctly in the webrev so it's hard to see the 
actual changes. Can you try a new recent webrev to see if that fixes it?

-Alan


On 17/02/2016 21:28, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8148346
>
> The proposed change is located at:
>
> http://cr.openjdk.java.net/~naoto/8148346/webrev.00/
>
> Vast majority of the changes are changing package names. They used to 
> be lang/ctry structure, which bloats the number of locale data package 
> names to hundreds. Now it comes down to 8 packages with this fix.
>
> Naoto


From nishit.jain at oracle.com  Thu Feb 18 10:08:45 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 18 Feb 2016 15:38:45 +0530
Subject: <i18n dev> Review Request for JDK-8074411: Describe "minor
 unit" and/or "default fraction digits" in Currency class' javadoc clearly
In-Reply-To: <56C1BFB6.4080805@oracle.com>
References: <56C1BFB6.4080805@oracle.com>
Message-ID: <56C5982D.7010401@oracle.com>

Hello All,

Please review the updated fix in "/Currency.java/".

The updated fix is located at:

Webrev: http://cr.openjdk.java.net/~rgoel/Nishit/8074411/webrev.01/ 
<http://cr.openjdk.java.net/%7Ergoel/Nishit/8074411/webrev.01/>

Changes made in the current version (webrev.01): Rephrasing of text in 
the /getDefaultFractionDigits()/ method description.

Regards,
Nishit Jain

On 2/15/2016 5:38 PM, Nishit Jain wrote:
> Hello All,
>
> Please review the following fix in "/Currency.java/".
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074411
> Webrev: http://cr.openjdk.java.net/~rgoel/Nishit/8074411/ 
> <http://cr.openjdk.java.net/%7Ergoel/Nishit/8074411/>
>
> Fix: A clarification about "minor units" and "default number of 
> fraction digits" is added in the specification. A suggestion to use 
> BigDecimal class while working with Currency or monetary values is 
> also added.
>
> Regards,
> Nishit Jain


From naoto.sato at oracle.com  Thu Feb 18 16:22:01 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 18 Feb 2016 08:22:01 -0800
Subject: <i18n dev> Review Request for JDK-8074411: Describe "minor
 unit" and/or "default fraction digits" in Currency class' javadoc clearly
In-Reply-To: <56C5982D.7010401@oracle.com>
References: <56C1BFB6.4080805@oracle.com> <56C5982D.7010401@oracle.com>
Message-ID: <56C5EFA9.9040207@oracle.com>

Looks good to me.

Naoto

On 2/18/16 2:08 AM, Nishit Jain wrote:
> Hello All,
>
> Please review the updated fix in "/Currency.java/".
>
> The updated fix is located at:
>
> Webrev: http://cr.openjdk.java.net/~rgoel/Nishit/8074411/webrev.01/
> <http://cr.openjdk.java.net/%7Ergoel/Nishit/8074411/webrev.01/>
>
> Changes made in the current version (webrev.01): Rephrasing of text in
> the /getDefaultFractionDigits()/ method description.
>
> Regards,
> Nishit Jain
>
> On 2/15/2016 5:38 PM, Nishit Jain wrote:
>> Hello All,
>>
>> Please review the following fix in "/Currency.java/".
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074411
>> Webrev: http://cr.openjdk.java.net/~rgoel/Nishit/8074411/
>> <http://cr.openjdk.java.net/%7Ergoel/Nishit/8074411/>
>>
>> Fix: A clarification about "minor units" and "default number of
>> fraction digits" is added in the specification. A suggestion to use
>> BigDecimal class while working with Currency or monetary values is
>> also added.
>>
>> Regards,
>> Nishit Jain
>

From naoto.sato at oracle.com  Thu Feb 18 17:50:57 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 18 Feb 2016 09:50:57 -0800
Subject: <i18n dev> [9] RFR: 8148346: Reduce number of packages in
 jdk.localedata module
In-Reply-To: <56C56DA6.7070602@oracle.com>
References: <56C4E5E3.1000204@oracle.com> <56C56DA6.7070602@oracle.com>
Message-ID: <56C60481.8010904@oracle.com>

Alan,

I updated the webrev with the latest webrev tool on OpenJDK site. Here 
is the revised one:

http://cr.openjdk.java.net/~naoto/8148346/webrev.01/

However, for some reason, the new webrev handles only .java files 
shuffling correctly, not for .properties files. They still remain all 
removed/created. Anyway what I did was to move all the resource files to 
language/country independent locations, and changed the "package" 
declarations in .java files.

Naoto

On 2/17/16 11:07 PM, Alan Bateman wrote:
>
> Naoto - I don't know if this is hg version or webrev related but the
> moves aren't showing up correctly in the webrev so it's hard to see the
> actual changes. Can you try a new recent webrev to see if that fixes it?
>
> -Alan
>
>
> On 17/02/2016 21:28, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8148346
>>
>> The proposed change is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8148346/webrev.00/
>>
>> Vast majority of the changes are changing package names. They used to
>> be lang/ctry structure, which bloats the number of locale data package
>> names to hundreds. Now it comes down to 8 packages with this fix.
>>
>> Naoto
>

From yuka.kamiya at oracle.com  Thu Feb 18 22:56:25 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 19 Feb 2016 07:56:25 +0900
Subject: <i18n dev> Review Request for JDK-8074411: Describe "minor
 unit" and/or "default fraction digits" in Currency class' javadoc clearly
In-Reply-To: <56C1BFB6.4080805@oracle.com>
References: <56C1BFB6.4080805@oracle.com>
Message-ID: <56C64C19.2070509@oracle.com>

Hi Nishit,

Your fix looks good to me.

Thanks,
--
Yuka


On 2016/02/15 21:08, Nishit Jain wrote:
> Hello All,
>
> Please review the following fix in "/Currency.java/".
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074411
> Webrev: http://cr.openjdk.java.net/~rgoel/Nishit/8074411/ 
> <http://cr.openjdk.java.net/%7Ergoel/Nishit/8074411/>
>
> Fix: A clarification about "minor units" and "default number of 
> fraction digits" is added in the specification. A suggestion to use 
> BigDecimal class while working with Currency or monetary values is 
> also added.
>
> Regards,
> Nishit Jain


From masayoshi.okutsu at oracle.com  Fri Feb 19 05:34:31 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 19 Feb 2016 14:34:31 +0900
Subject: <i18n dev> [9] RFR: 8148346: Reduce number of packages in
 jdk.localedata module
In-Reply-To: <56C60481.8010904@oracle.com>
References: <56C4E5E3.1000204@oracle.com> <56C56DA6.7070602@oracle.com>
	<56C60481.8010904@oracle.com>
Message-ID: <56C6A967.7090905@oracle.com>

This one is much easier to take a look than the previous webrevs. This 
time I've looked at all diffs while I did a sampling for our internal 
review.

Looks OK to me. I still prefer the per-language (not 
per-language.country) grouping, though.

Masayoshi

On 2/19/2016 2:50 AM, Naoto Sato wrote:
> Alan,
>
> I updated the webrev with the latest webrev tool on OpenJDK site. Here 
> is the revised one:
>
> http://cr.openjdk.java.net/~naoto/8148346/webrev.01/
>
> However, for some reason, the new webrev handles only .java files 
> shuffling correctly, not for .properties files. They still remain all 
> removed/created. Anyway what I did was to move all the resource files 
> to language/country independent locations, and changed the "package" 
> declarations in .java files.
>
> Naoto
>
> On 2/17/16 11:07 PM, Alan Bateman wrote:
>>
>> Naoto - I don't know if this is hg version or webrev related but the
>> moves aren't showing up correctly in the webrev so it's hard to see the
>> actual changes. Can you try a new recent webrev to see if that fixes it?
>>
>> -Alan
>>
>>
>> On 17/02/2016 21:28, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8148346
>>>
>>> The proposed change is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8148346/webrev.00/
>>>
>>> Vast majority of the changes are changing package names. They used to
>>> be lang/ctry structure, which bloats the number of locale data package
>>> names to hundreds. Now it comes down to 8 packages with this fix.
>>>
>>> Naoto
>>


From Alan.Bateman at oracle.com  Fri Feb 19 08:17:52 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Feb 2016 08:17:52 +0000
Subject: <i18n dev> [9] RFR: 8148346: Reduce number of packages in
 jdk.localedata module
In-Reply-To: <56C6A967.7090905@oracle.com>
References: <56C4E5E3.1000204@oracle.com> <56C56DA6.7070602@oracle.com>
	<56C60481.8010904@oracle.com> <56C6A967.7090905@oracle.com>
Message-ID: <56C6CFB0.9090406@oracle.com>



On 19/02/2016 05:34, Masayoshi Okutsu wrote:
> This one is much easier to take a look than the previous webrevs. This 
> time I've looked at all diffs while I did a sampling for our internal 
> review.
>
> Looks OK to me. I still prefer the per-language (not 
> per-language.country) grouping, though.
>
> Masayoshi
Thanks for the updating the webrev, much easier to read now.

I think the changes are okay. I don't have a strong opinion on the 
grouping and it looks like it could be easy to change if we look at it 
again.

-Alan

From naoto.sato at oracle.com  Tue Feb 23 18:20:20 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 23 Feb 2016 10:20:20 -0800
Subject: <i18n dev> [9] RFR: 8150434: Remove redundant "jdk_localedata" from
 the CLDR locale data meta info class name
Message-ID: <56CCA2E4.4000107@oracle.com>

Hello,

Please review this small fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8150434

The fix is located at:

http://cr.openjdk.java.net/~naoto/8150434/webrev.00/

Naoto

From mandy.chung at oracle.com  Tue Feb 23 18:45:10 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 23 Feb 2016 10:45:10 -0800
Subject: <i18n dev> [9] RFR: 8150434: Remove redundant "jdk_localedata"
	from the CLDR locale data meta info class name
In-Reply-To: <56CCA2E4.4000107@oracle.com>
References: <56CCA2E4.4000107@oracle.com>
Message-ID: <6471EE53-3542-4AC2-9CD4-4957A8499539@oracle.com>


> On Feb 23, 2016, at 10:20 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Hello,
> 
> Please review this small fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8150434
> 
> The fix is located at:
> 
> http://cr.openjdk.java.net/~naoto/8150434/webrev.00/

+1

Dropping the _jdk_localedata suffix from the class name is good.  Thanks for making the change.

Mandy

From ramanand.patil at oracle.com  Wed Feb 24 07:40:48 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 23 Feb 2016 23:40:48 -0800 (PST)
Subject: <i18n dev> RFR: JDK-8087104: DateFormatSymbols triggers
 this.clone() in the constructor
Message-ID: <de93a79f-e4ed-4d97-b385-0431f5570638@default>

Hi all,
Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104
Bug Description: DateFormatSymbols caches its own instance and calls this.clone() in the constructor. Because of this, any subclass implementation (which expects a field is always initialized to non-null in the constructor) will throw NPE in its overridden clone() method while using any instance variables which it assumed are initilaized in its contructor.
Webrev: http://cr.openjdk.java.net/~rpatil/8087104/webrev.00/
Fix: Instead of using its own instance for caching and calling clone in DateFormatSymbols, a nested class SymbolsCacheEntry is introduced.
 

Regards,

Ramanand.

From masayoshi.okutsu at oracle.com  Wed Feb 24 08:16:25 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 24 Feb 2016 17:16:25 +0900
Subject: <i18n dev> RFR: JDK-8087104: DateFormatSymbols triggers
 this.clone() in the constructor
In-Reply-To: <de93a79f-e4ed-4d97-b385-0431f5570638@default>
References: <de93a79f-e4ed-4d97-b385-0431f5570638@default>
Message-ID: <56CD66D9.9070605@oracle.com>

Looks good to me.

Masayoshi

On 2/24/2016 4:40 PM, Ramanand Patil wrote:
> Hi all,
> Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104
> Bug Description: DateFormatSymbols caches its own instance and calls this.clone() in the constructor. Because of this, any subclass implementation (which expects a field is always initialized to non-null in the constructor) will throw NPE in its overridden clone() method while using any instance variables which it assumed are initilaized in its contructor.
> Webrev: http://cr.openjdk.java.net/~rpatil/8087104/webrev.00/
> Fix: Instead of using its own instance for caching and calling clone in DateFormatSymbols, a nested class SymbolsCacheEntry is introduced.
>   
>
> Regards,
>
> Ramanand.


From peter.levart at gmail.com  Wed Feb  3 11:07:20 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 03 Feb 2016 11:07:20 -0000
Subject: <i18n dev> RFR JDK-7071819: To support Extended Grapheme
	Clusters in Regex
In-Reply-To: <56B11EC3.3010505@oracle.com>
References: <569DEB35.7020006@oracle.com> <56B11EC3.3010505@oracle.com>
Message-ID: <56B1DF63.2040708@gmail.com>

Hi Sherman,

I don't currently have any idea how to squeeze the hashtable any more 
further. It is already very compact in my opinion. But I noticed a data 
race that could result in navigating the half-initialized data 
structure. It is a classical unsafe publication bug. It has been present 
before in get(int cp) and it is present now in both getName(int cp) and 
getCodePoint(String name). For example:

  151     static int getCodePoint(String name) {
  152         byte[] strPool = null;
  153         if (refStrPool == null || (strPool = refStrPool.get()) == 
null) {
  154             strPool = initNamePool();
  155         }

vs.

111             refStrPool = new SoftReference<>(strPool);

...the static refStrPool field is not marked volatile.

One way to fix this is to mark field volatile and then rearrange code in 
getName/getCodePoint to only read from it once by introducing a local 
var. The other would be to change the line 111 into something like:

SoftReference<byte[]> rsp = new SoftReference<>(strPool);
unsafe.storeFence();
refStrPool = rsp;

...*and* also rearrange code in getName/getCodePoint to only read from 
field once by introducing a local var.


Regards, Peter

On 02/02/2016 10:25 PM, Xueming Shen wrote:
> Hi,
>
> Have not heard any feedback on this one so far. I'm adding
> a little more to make it attractive for reviewers :-)
>
> On top of the \N now the webrev includes the proposal to add
> two more matchers, \X for unicode extended grapheme cluster
> and \b{g} for the corresponding boundary.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-7071819
> Issue: https://bugs.openjdk.java.net/browse/JDK-8147531
> webrev: http://cr.openjdk.java.net/~sherman/8147531_7071819/webrev/
>
> Thanks!
> Sherman
>
> On 01/18/2016 11:52 PM, Xueming Shen wrote:
>> Hi,
>>
>> Please help review the change to add \N support in regex.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8147531
>> webrev: http://cr.openjdk.java.net/~sherman/8147531/webrev
>>
>> This is one of the items we were planning to address via JEP111
>> http://openjdk.java.net/jeps/111
>> https://bugs.openjdk.java.net/browse/JDK-8046101
>>
>> Some of the constructs had been added already in early release. I'm
>> planning to address the rest as individual rfe separately.
>>
>> Thanks,
>> Sherman
>


From peter.levart at gmail.com  Wed Feb  3 11:26:43 2016
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 03 Feb 2016 11:26:43 -0000
Subject: <i18n dev> RFR JDK-7071819: To support Extended Grapheme
	Clusters in Regex
In-Reply-To: <56B1DF63.2040708@gmail.com>
References: <569DEB35.7020006@oracle.com> <56B11EC3.3010505@oracle.com>
	<56B1DF63.2040708@gmail.com>
Message-ID: <56B1E3EC.2060509@gmail.com>

Hi Again,

I also have a comment on the implementation of the hash table and it's 
GC-ness. You keep the string pool under a SoftReference because it is 
the biggest object so it makes most sense to clear it when heap becomes 
full. Other arrays are kept strongly reachable, but you re-generate them 
nevertheless when string pool is cleared by GC. Would it make sense to:

- define all int[] arrays (including strPool) as final instance 
variables of CharacterName
- have one static field:

private static SoftReference<CharacterName> refInstance;

- convert initNamePool() into a private constructor.

- convert public static getName/getCodePoint into public instance methods

- introduce public static method:

public static CharacterName getInstance() {
     SoftReference<CharacterName> ref = refInstance;
     CharacterName instance;
     if (ref != null && ((instance = ref.get) != null) {
         return instance;
     }
     instance = new CharacterName();
     refInstance = new SoftReference<>(instance);
     return instance;
}

...in this arrangement, you don't need volatile fields or explicit 
fences, as all instance fields can be final and JMM guarantees safe 
publication in this case.


Regards, Peter

On 02/03/2016 12:07 PM, Peter Levart wrote:
> Hi Sherman,
>
> I don't currently have any idea how to squeeze the hashtable any more 
> further. It is already very compact in my opinion. But I noticed a 
> data race that could result in navigating the half-initialized data 
> structure. It is a classical unsafe publication bug. It has been 
> present before in get(int cp) and it is present now in both 
> getName(int cp) and getCodePoint(String name). For example:
>
>  151     static int getCodePoint(String name) {
>  152         byte[] strPool = null;
>  153         if (refStrPool == null || (strPool = refStrPool.get()) == 
> null) {
>  154             strPool = initNamePool();
>  155         }
>
> vs.
>
> 111             refStrPool = new SoftReference<>(strPool);
>
> ...the static refStrPool field is not marked volatile.
>
> One way to fix this is to mark field volatile and then rearrange code 
> in getName/getCodePoint to only read from it once by introducing a 
> local var. The other would be to change the line 111 into something like:
>
> SoftReference<byte[]> rsp = new SoftReference<>(strPool);
> unsafe.storeFence();
> refStrPool = rsp;
>
> ...*and* also rearrange code in getName/getCodePoint to only read from 
> field once by introducing a local var.
>
>
> Regards, Peter
>
> On 02/02/2016 10:25 PM, Xueming Shen wrote:
>> Hi,
>>
>> Have not heard any feedback on this one so far. I'm adding
>> a little more to make it attractive for reviewers :-)
>>
>> On top of the \N now the webrev includes the proposal to add
>> two more matchers, \X for unicode extended grapheme cluster
>> and \b{g} for the corresponding boundary.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-7071819
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8147531
>> webrev: http://cr.openjdk.java.net/~sherman/8147531_7071819/webrev/
>>
>> Thanks!
>> Sherman
>>
>> On 01/18/2016 11:52 PM, Xueming Shen wrote:
>>> Hi,
>>>
>>> Please help review the change to add \N support in regex.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8147531
>>> webrev: http://cr.openjdk.java.net/~sherman/8147531/webrev
>>>
>>> This is one of the items we were planning to address via JEP111
>>> http://openjdk.java.net/jeps/111
>>> https://bugs.openjdk.java.net/browse/JDK-8046101
>>>
>>> Some of the constructs had been added already in early release. I'm
>>> planning to address the rest as individual rfe separately.
>>>
>>> Thanks,
>>> Sherman
>>
>