Re: java.lang.Character lacuna #1 of 2

2011-04-26 Thread Tom Christiansen
>I have filed CR/RFE 7036910: >j.l.Character.toLowerCaseCharArray/toTitleCaseCharArray for this request. Thanks very much. > The j.l.Character.toLowerCase/toUpperCase() suggests to use > String.toLower/UpperCase() for case mapping, if you want 1:M mapping > taken care. And if you trust the API:-

Re: Proposed update to UTS#18

2011-04-26 Thread Tom Christiansen
Andy Heninger wrote: >>> I actually had do this because I have a dataset that has things like >>> "undeaðlich" nad "smørrebrød", and I wanted to allow the user to >>> head-match with "undead" and "smor", respectively. There is no >>> decomposition of "ð" that includes "d", nor any of "ø" that in

hg: jdk7/l10n/langtools: 44 new changesets

2011-04-26 Thread michael . fang
Changeset: 6970d9fb8e02 Author:ksrini Date: 2011-03-07 17:39 -0800 URL: http://hg.openjdk.java.net/jdk7/l10n/langtools/rev/6970d9fb8e02 7021927: javac: regression in performance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/

java.lang.Character lacuna #1 of 2

2011-04-26 Thread Tom Christiansen
Sherman, While I was fixing your docs for j.l.Character, I kept the Unicode 6.0 specs close at hand to make sure everything was up to date. That's how I was able to discover that one could safely update this comment that noted that 1:M uppercasings happen only in the BMP: -// As of

hg: jdk7/l10n/corba: 2 new changesets

2011-04-26 Thread michael . fang
Changeset: e0b72ae5dc5e Author:schien Date: 2011-03-17 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/l10n/corba/rev/e0b72ae5dc5e Added tag jdk7-b134 for changeset 918003855fa0 ! .hgtags Changeset: 48ef0c712e7c Author:schien Date: 2011-03-24 11:20 -0700 URL: http:

Re: Fwd: Some differences on Window UDC area

2011-04-26 Thread Charles Lee
On 03/28/2011 11:06 PM, Alan Bateman wrote: Charles Lee wrote: : It looks similar. How can I find the patch quickly? I notice it says "the list is attached to this CR". Is it CR-6183404? Since cr has the pattern cr.openjdk.java.net/~username/id, how can I know who is the committer to this CR

Re: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties

2011-04-26 Thread Xueming Shen
Thanks Mark! Let's go with UNICODE_PROPERTY, if there is no objection. -Sherman On 4/24/2011 9:00 PM, Mark Davis ☕ wrote: There are pluses and minuses to any of them: UNICODE_SPEC, UNICODE_PROPERTY, UNICODE_CLASS, UNICODE_PROPERTIES, or UNICODE_CLASSES, although any would work in a pinch.

hg: jdk7/l10n: 6 new changesets

2011-04-26 Thread michael . fang
Changeset: a1c8b847b753 Author:ohrstrom Date: 2011-02-28 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/l10n/rev/a1c8b847b753 7021753: Add a build times report Summary: Report the build times at end of a jdkroot build. Reviewed-by: ohair ! Makefile ! make/Defs-internal.gmk ! make

Re: Codereview request for 7033561: Missing Unicode Script aliases

2011-04-26 Thread Yuka Kamiya
Hi Sherman, The fix looks good to me. Thanks, -- Yuka (11/04/07 5:16), Xueming Shen wrote: It appears the aliases mapping for Character.UnicodeScript is not updated accordingly when we upgraded the Unicode support to 6.0 for JDK7. The difference between the previous version (5.2) and 6.0 of

Re: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties

2011-04-26 Thread Xueming Shen
On 04-26-2011 2:20 AM, Alan Bateman wrote: Xueming Shen wrote: Thanks Mark! Let's go with UNICODE_PROPERTY, if there is no objection. I went through the updates to the javadoc and the approach looks good and nicely done. A minor comment is that the compile(String,int) method repeats the list

Re: Fwd: Re: Codereview Request: 7039066 j.u.rgex does not match TR#18 RL1.4 Simple Word Boundaries and RL1.2 Properties

2011-04-26 Thread Alan Bateman
Xueming Shen wrote: Thanks Mark! Let's go with UNICODE_PROPERTY, if there is no objection. I went through the updates to the javadoc and the approach looks good and nicely done. A minor comment is that the compile(String,int) method repeats the list of flags that are allowed so that should be