From ramanand.patil at oracle.com  Wed Mar  2 05:34:09 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 1 Mar 2016 21:34:09 -0800 (PST)
Subject: <i18n dev> RFR: JDK-8087104: DateFormatSymbols triggers
 this.clone() in the constructor
In-Reply-To: <56CD66D9.9070605@oracle.com>
References: <de93a79f-e4ed-4d97-b385-0431f5570638@default>
	<56CD66D9.9070605@oracle.com>
Message-ID: <1e1da08c-4e32-4109-84da-94835ef4f028@default>

Hi all,

May I request one more review for this bug?

[Thank you Masayoshi for your review.]


Regards,
Ramanand.

-----Original Message-----
From: Masayoshi Okutsu 
Sent: Wednesday, February 24, 2016 1:46 PM
To: Ramanand Patil; i18n-dev at openjdk.java.net
Cc: core-libs-dev at openjdk.java.net
Subject: Re: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor

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 yuka.kamiya at oracle.com  Wed Mar  2 07:52:13 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Wed, 2 Mar 2016 16:52:13 +0900
Subject: <i18n dev> RFR: JDK-8087104: DateFormatSymbols triggers
 this.clone() in the constructor
In-Reply-To: <1e1da08c-4e32-4109-84da-94835ef4f028@default>
References: <de93a79f-e4ed-4d97-b385-0431f5570638@default>
	<56CD66D9.9070605@oracle.com>
	<1e1da08c-4e32-4109-84da-94835ef4f028@default>
Message-ID: <56D69BAD.50605@oracle.com>

Hi Ramanand,

Your fix looks good to me.

Thanks,
--
Yuka

On 2016/03/02 14:34, Ramanand Patil wrote:
> Hi all,
>
> May I request one more review for this bug?
>
> [Thank you Masayoshi for your review.]
>
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Masayoshi Okutsu
> Sent: Wednesday, February 24, 2016 1:46 PM
> To: Ramanand Patil; i18n-dev at openjdk.java.net
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor
>
> 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 joe.darcy at oracle.com  Mon Mar  7 19:25:39 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 7 Mar 2016 11:25:39 -0800
Subject: <i18n dev> JDK 9 RFR of JDK-8151393: Revert changes for JDK-8087104
Message-ID: <56DDD5B3.1040705@oracle.com>

Hello,

The changes for JDK-8087104 introduced some test failures which have not 
yet been addressed (JDK-8151310). In order to get a clean snapshot for 
the next integration, if the fix for JDK-8151310 doesn't arrive in time, 
the changes for JDK-8087104 should be reverted until they can be 
otherwise corrected.

In case the fix doesn't arrive, I patch -R'ed the changset for 
JDK-8087104. The (anti)diff to DateFormatSymbols.java is below; the 
newly-introduced failing test file from the previous changeset

     test/java/text/Format/DateFormat/DFSConstructorCloneTest.java

is deleted.

Thanks,

-Joe

--- a/src/java.base/share/classes/java/text/DateFormatSymbols.java Fri 
Mar 04 10:09:54 2016 -0800
+++ b/src/java.base/share/classes/java/text/DateFormatSymbols.java Mon 
Mar 07 11:20:50 2016 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -606,7 +606,7 @@
          try
          {
              DateFormatSymbols other = (DateFormatSymbols)super.clone();
-            copyMembers(new SymbolsCacheEntry(locale), other);
+            copyMembers(this, other);
              return other;
          } catch (CloneNotSupportedException e) {
              throw new InternalError(e);
@@ -669,7 +669,7 @@
      /**
       * Cache to hold DateFormatSymbols instances per Locale.
       */
-    private static final ConcurrentMap<Locale, 
SoftReference<SymbolsCacheEntry>> cachedInstances
+    private static final ConcurrentMap<Locale, 
SoftReference<DateFormatSymbols>> cachedInstances
          = new ConcurrentHashMap<>(3);

      private transient int lastZoneIndex;
@@ -683,10 +683,10 @@
          locale = desiredLocale;

          // Copy values of a cached instance if any.
-        SoftReference<SymbolsCacheEntry> ref = cachedInstances.get(locale);
-        SymbolsCacheEntry sce;
-        if (ref != null && (sce = ref.get()) != null) {
-            copyMembers(sce, this);
+        SoftReference<DateFormatSymbols> ref = cachedInstances.get(locale);
+        DateFormatSymbols dfs;
+        if (ref != null && (dfs = ref.get()) != null) {
+            copyMembers(dfs, this);
              return;
          }

@@ -717,11 +717,11 @@
          weekdays = toOneBasedArray(resource.getStringArray("DayNames"));
          shortWeekdays = 
toOneBasedArray(resource.getStringArray("DayAbbreviations"));

-        sce = new SymbolsCacheEntry(locale);
-        ref = new SoftReference<>(sce);
-        SoftReference<SymbolsCacheEntry> x = 
cachedInstances.putIfAbsent(locale, ref);
+        // Put a clone in the cache
+        ref = new SoftReference<>((DateFormatSymbols)this.clone());
+        SoftReference<DateFormatSymbols> x = 
cachedInstances.putIfAbsent(locale, ref);
          if (x != null) {
-            SymbolsCacheEntry y = x.get();
+            DateFormatSymbols y = x.get();
              if (y == null) {
                  // Replace the empty SoftReference with ref.
                  cachedInstances.put(locale, ref);
@@ -812,7 +812,7 @@
       * @param src the source DateFormatSymbols.
       * @param dst the target DateFormatSymbols.
       */
-    private void copyMembers(SymbolsCacheEntry src, DateFormatSymbols dst)
+    private void copyMembers(DateFormatSymbols src, DateFormatSymbols dst)
      {
          dst.eras = Arrays.copyOf(src.eras, src.eras.length);
          dst.months = Arrays.copyOf(src.months, src.months.length);
@@ -821,7 +821,7 @@
          dst.shortWeekdays = Arrays.copyOf(src.shortWeekdays, 
src.shortWeekdays.length);
          dst.ampms = Arrays.copyOf(src.ampms, src.ampms.length);
          if (src.zoneStrings != null) {
-            dst.zoneStrings = getZoneStringsImpl(true);
+            dst.zoneStrings = src.getZoneStringsImpl(true);
          } else {
              dst.zoneStrings = null;
          }
@@ -842,43 +842,4 @@
          }
          stream.defaultWriteObject();
      }
-
-    private static class SymbolsCacheEntry {
-
-        final String eras[];
-        final String months[];
-        final String shortMonths[];
-        final String weekdays[];
-        final String shortWeekdays[];
-        final String ampms[];
-        final String zoneStrings[][];
-        final String localPatternChars;
-
-        SymbolsCacheEntry(Locale locale) {
-            // Initialize the fields from the ResourceBundle for locale.
-            LocaleProviderAdapter adapter = 
LocaleProviderAdapter.getAdapter(DateFormatSymbolsProvider.class, locale);
-            // Avoid any potential recursions
-            if (!(adapter instanceof ResourceBundleBasedAdapter)) {
-                adapter = LocaleProviderAdapter.getResourceBundleBased();
-            }
-            ResourceBundle resource = ((ResourceBundleBasedAdapter) 
adapter).getLocaleData().getDateFormatData(locale);
-            if (resource.containsKey("Eras")) {
-                this.eras = resource.getStringArray("Eras");
-            } else if (resource.containsKey("long.Eras")) {
-                this.eras = resource.getStringArray("long.Eras");
-            } else if (resource.containsKey("short.Eras")) {
-                this.eras = resource.getStringArray("short.Eras");
-            } else {
-                this.eras = null;
-            }
-            this.months = resource.getStringArray("MonthNames");
-            this.shortMonths = 
resource.getStringArray("MonthAbbreviations");
-            this.weekdays = 
toOneBasedArray(resource.getStringArray("DayNames"));
-            this.shortWeekdays = 
toOneBasedArray(resource.getStringArray("DayAbbreviations"));
-            this.ampms = resource.getStringArray("AmPmMarkers");
-            this.zoneStrings = TimeZoneNameUtility.getZoneStrings(locale);
-            this.localPatternChars = 
resource.getString("DateTimePatternChars");
-
-        }
-    }
  }


From ramanand.patil at oracle.com  Wed Mar 16 19:38:38 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Wed, 16 Mar 2016 12:38:38 -0700 (PDT)
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016b
Message-ID: <2ac381e9-521e-468c-abc8-b3e7ce13b4f5@default>

Hi all,

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

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

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

All the TimeZone related tests are passed after integration.

 

Please note that, as per the release notes: As a trial of a new system that needs less information to be made up, the new zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".

Since this is a trial system, I have ignored this in the current patch which adds 3 new timezones. But I think it's worth discussing this new system along with this bug and get the experts opinion on this.

Do you think that JDK should also follow these IANA timezone naming system for zone abbreviations in future ?  Will it be convenient to use such numeric time zone abbreviations ? (Also, it looks like the abbreviations similar to "+03/+04" will be used for the zones linked to the rule set with changing letters like: EST/EDT for US, MSK/MSD for RU, etc..).

 

Regards,

Ramanand.

 

From philip.race at oracle.com  Thu Mar 17 19:54:25 2016
From: philip.race at oracle.com (Phil Race)
Date: Thu, 17 Mar 2016 12:54:25 -0700
Subject: <i18n dev> [OpenJDK 2D-Dev] [9] Review request for 8073400:
 Some Monospaced logical fonts have a different width
In-Reply-To: <56C46F35.6030107@oracle.com>
References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com>
	<56C46F35.6030107@oracle.com>
Message-ID: <56EB0B71.8090000@oracle.com>

I think you are still waiting on i18n to reply here since the exclusion 
ranges
are mainly used for ensuring that the glyphs come from the right font which
is mainly for locale reasons. If i18n see no problems then I am OK with 
this.

-phil.

On 02/17/2016 05:01 AM, dmitry markov wrote:
> 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 xueming.shen at oracle.com  Fri Mar 18 05:18:40 2016
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 17 Mar 2016 22:18:40 -0700
Subject: <i18n dev> RFR: Regex canonical equivalents
Message-ID: <56EB8FB0.1010809@oracle.com>

Hi,

While still waiting patiently for the review for

RFR: Regex exponential backtracking issue [1]
RFR: Regex exponential backtracking issue --- more cleanup/tuning [2]

Here is the third round of change to address the "broken canonical 
equivalent support"
issue listed in JEP-111 [3] .

Canonical Equivalents:

Unicode Standard defines "canonical equivalents" in its tr18# [4]. The 
"canonical equivalents"
related item has been updated lot of times. It appears the standard 
itself has kinda given up
on defining a "general approach" for the regex engine :-) with the 
wordings "In practice, regex
APIs are not setup to match parts of .... it is feasible, however, to 
construct patterns that will
match against NFD ..." The "canonical equivalents" is just too 
complicated and too many
edge cases for a "normal" regex engine and its APIs.

We probably should have optioned to not support it if had the choice 
again. Unfortunately
Java regex has spec-ed to support such "canonical equivalents" from the 
very beginning
and has been "supporting" this feature with something that least works 
reasonably in some
common cases for releases.

The current regex CANON_EQ support is kinda of broken, especially the 
implementation for
the character class construct. It simply does not work as expected, as 
reported in various
issues listed below.

https://bugs.openjdk.java.net/browse/JDK-4916384
https://bugs.openjdk.java.net/browse/JDK-4867170
https://bugs.openjdk.java.net/browse/JDK-6995635
https://bugs.openjdk.java.net/browse/JDK-6728861
https://bugs.openjdk.java.net/browse/JDK-6736245
https://bugs.openjdk.java.net/browse/JDK-7080302

How does the java regex "work" now when the CANON_EQ flag is set? the 
current
implementation first

(1) converts the whole pattern into Normalizer.Form.NFD form, for 
example for
the greek extended character "\u1f80", we convert it to its nfd form as

\u1f80 -> \u03b1\u0313\u0345

which has a base character \u03b1 (small alpha) followed by two 
non-spacing_mark
characters \u0313 (combining comma above) and \u0345 (greek iota below)

(2) then we generate all the possible "permutations" of the characters 
inside the nfd
string (based on the unicode nfd/nfc normalization rules, the base 
character stays
where it is, those non-space-mark characters can be in any order for NOT 
normalized
text), which includes the possible new "combination" of individual each 
characters.

\u3b1\u313\u345
\u3b1\u345\u313
\u1f00\u345 (new combination \u3b1\u0313 -> \u1f00)
\u1fb3\u313 (new combination \u3b1\u0345 -> \u1fb3)
\u1f80

(3) finally a pure group is constructed with the permutations, which 
will match
any canonical equivalences, to replace the original single \u1f80

(?:\u1f80|\u3b1\u313\u345|\u1f00\u345|\u3b1\u345\u313|\u1fb3\u313)

The resulting pure group, though looks tedious, can match all the canonical
equivalences (are literally listed as the "alternation" inside the pure 
group construct)
of the greek character \u1f80, especially in "literal" case (slice of 
characters). For
example, pattern "A\u1f80B" matches successfully for input like

"A\u3b1\u313\u345B"
"A\u3b1\u345\u313B"
"A\u1f00\u345B"
"A\u1fb3\u313B"
"A\u1f80B"

And it works fine even you put it inside a character class construct 
[...] The pattern
"[\u1f80]" can successfully find its corresponding canonical 
equivalences from the
above input strings.

But it starts to fail apart when you try a little more "complicated" 
character class, for
example, the negation [^\u1f80A] does not match A but matches \u1f80, 
and match
all of its canonical equivalences.

Range [\u1f80-\u1f82] matches \u1f80, \u1f82 and their canonical 
equivalences, as
expected but it doesn't match \u1f81 (and its canonical equivalences), 
as people would
normally expected (as \u1f81 is perfectly inside that range) .

The reason behind these failures is because the current implementation 
converts/
normalizes the "character class" pattern the same way as it does for the 
"slice of
characters" pattern. Take a look at the "normalized" pattern from the 
character class
samples,

[^\u1f80A]
--> 
(?:[^A]|\u3b1\u313\u345|\u1f00\u345|\u1f80|\u3b1\u345\u313|\u1fb3\u313|\u1f80)

[\u1f80-\u1f82]
--> 
(?:[-]|\u3b1\u313\u345|\u1f00\u345|\u1f80|\u3b1\u345\u313|\u1fb3\u313|\u1f80|\u3b1\u313\u300\u345|...)

The current implementation simply takes those "composed" characters out 
of the
character class body, converts them into alternations (as it does for 
the slice)
and append them at the end of the character class construct. It just 
does not work,
the resulting pattern does not really match what the original regex 
pattern means
to be.

[^\u1f80A]  -> any character neither is 'A' nor \u1f8a", including their 
canonical
                         equivalences.
[[\u1f80-\u1f82] ]
                   -> any character (including their canonical 
equivalences) with the range
                        of \u1f80 andu1f82

The proposed changes here are

(1) instead of normalizing everything of the pattern into nfd, 
normalizing the character
class part into nfc, as the "character class" really needs to match a 
"character" or the
"canonical equivalence" of this "character (composed). It can be 
interpreted as to match
a "grapheme" that can be normalized into a "nfc" that matches this 
"character". For
example if you have a  luster of \u03b1\u0314\u0345" inside a character 
class, it is
reasonable to assume you really mean to match character \u1f80 and/its 
canonical
equivalences, when the CANON_EQ when the flag is on.

(2) instead of trying to generate the permutations, create the 
alternation and then put
it appropriately into the character class (logically), we now use a 
special "Node", the
NFCCharProperty to do the matching work. The NFCCharProperty tries to 
match a
grapheme cluster at a time (nfc greedly, then backtrack) against the 
character class.

For example for character class [\u1f80] or [\u03b1\u0313\u0345] the 
resulting
"normalized "pattern is [\u1f80]

and for the negation the "normalized" pattern is a normal [^\u1f80] for 
both [^\u1f80]
and [^\u03b1\u0313\u0345]

When matching,  we try to match the input against the targeting 
character class
grapheme by grapheme. The engine picks a grapheme cluster first, 
normalize it
to its NFC form, and then match it against the character class.

For example,

input text:  "ab\u1f81cd"
                   "ab\u03b1\u0314\u0345cd"
                   "ab\u03b1\u0345\u0314cd"
                   "ab\u1f01\u0345cd"
                   "ab\u1fb3\u0314cd"

character class: [\u1f80-\u1f82],

The engine finds the grapheme cluster "\u03b1\u0314\u0345" (or any of 
the other combination)
first, normalize it into \u1f81, match it against the range 
\u1f80-\u1f82, and move on.

In case there is(are) extra non-spacing-mark character in the grapheme 
cluster, for example

"ab\u03b1\u0314\u0345\u0313cd"    (there is any extra \u0313")

The "find" will still have a "find" at \u03b1\u0314\u0345. But the input 
will not "match"
"ab[\u1f80-\u1f82]cd" (because there is extra), but it will "match" 
"ab[\u1f80-\u1f82]\u0313cd".

(as an implementation detail, the engine will first try 
"\u03b1\u0314\u0345\u0313",
which ends up with a nfc string"\u1f81\u0313", can NOT match the single 
character, it backtracks
to "\u03b1\u0314\u0345" ...)


The approach seems to work and fix most of the troubles we have in 
character class.

Here is the webrev (on top of the changes for JDK-8151481 [1])

http://cr.openjdk.java.net/~sherman/regexCE/webrev/


While the character class CANON_EQ support is the main issue we want to 
address
this time, there are also couple other problems reported in the past, 
they are fixed
together here.

(1) the current implement only supports base+non_spacing_marks CANON_EQ, 
the
the canonical equivalence of decomposed hangul (jamos) and composed hangl
syllables is NOT supported, for example "\u1100\u1161" vs "\uac00".

fixed.

(2) Character in Unicode composition exclusion table does not match 
itself, as
reported in JDK-6736245. (special composition sample,
nfd(\u2adc) -> \u2add\u0338
nfc(\u2add\u0338) -> \u2add\u0338 (NOT back to \u2adc)

fixed.

(3) regex compiling syntax error/exception when compile certain regex, 
for example
"(\u00e9)" triggers

Exception in thread "main" java.util.regex.PatternSyntaxException: 
Unmatched closing ')' near index 11
((?:e??)|??)|e)??)
^
fixed.

(4) the canonical equivalence does not work for the property class
"\\p{IsGreek}" matches "\u1f80"
"\\p{IsGreek}" but does match "\u1f00\u0345\u0300"

works as expected now.

thanks,
Sherman


[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039269.html
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039404.html
[3] http://openjdk.java.net/jeps/111
[4] http://unicode.org/reports/tr18/#Canonical_Equivalents

From naoto.sato at oracle.com  Fri Mar 18 18:09:42 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 18 Mar 2016 11:09:42 -0700
Subject: <i18n dev> [OpenJDK 2D-Dev] [9] Review request for 8073400:
 Some Monospaced logical fonts have a different width
In-Reply-To: <56EB0B71.8090000@oracle.com>
References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com>
	<56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com>
Message-ID: <56EC4466.8020506@oracle.com>

So this fix will replace those left-right quotation marks in those CJK 
locales from locale-specific font to "alphabetic", right? I don't know 
much about the history (and personally I am fine with the fix), but 
should we consult with the globalization team?

Naoto

On 3/17/16 12:54 PM, Phil Race wrote:
> I think you are still waiting on i18n to reply here since the exclusion
> ranges
> are mainly used for ensuring that the glyphs come from the right font which
> is mainly for locale reasons. If i18n see no problems then I am OK with
> this.
>
> -phil.
>
> On 02/17/2016 05:01 AM, dmitry markov wrote:
>> 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 xueming.shen at oracle.com  Fri Mar 18 20:05:10 2016
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 18 Mar 2016 13:05:10 -0700
Subject: <i18n dev> RFR: regex changes
Message-ID: <56EC5F76.4080106@oracle.com>

Hi,

There are couple regex related changes waiting for review. I have pull them
together here (with the notes) to make it easy to review.

http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/

(1) Exponential backtracking

Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking

https://bugs.openjdk.java.net/browse/JDK-6328855
https://bugs.openjdk.java.net/browse/JDK-6192895
https://bugs.openjdk.java.net/browse/JDK-6345469
https://bugs.openjdk.java.net/browse/JDK-6988218
https://bugs.openjdk.java.net/browse/JDK-6693451
https://bugs.openjdk.java.net/browse/JDK-7006761
https://bugs.openjdk.java.net/browse/JDK-8140212

(2) Anonymous class to lambda function cleanup

Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction

https://bugs.openjdk.java.net/browse/JDK-8151481
https://bugs.openjdk.java.net/browse/JDK-6609854

(3) Canonical Equivalents

Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ

https://bugs.openjdk.java.net/browse/JDK-4916384
https://bugs.openjdk.java.net/browse/JDK-4867170
https://bugs.openjdk.java.net/browse/JDK-6995635
https://bugs.openjdk.java.net/browse/JDK-6728861
https://bugs.openjdk.java.net/browse/JDK-6736245
https://bugs.openjdk.java.net/browse/JDK-7080302

Thanks
Sherman

From philip.race at oracle.com  Fri Mar 18 20:17:17 2016
From: philip.race at oracle.com (Phil Race)
Date: Fri, 18 Mar 2016 13:17:17 -0700
Subject: <i18n dev> [OpenJDK 2D-Dev] [9] Review request for 8073400:
 Some Monospaced logical fonts have a different width
In-Reply-To: <56EC4466.8020506@oracle.com>
References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com>
	<56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com>
	<56EC4466.8020506@oracle.com>
Message-ID: <56EC624D.60700@oracle.com>

I doubt that the G11N team would have any clue about this ..

-phil.

On 03/18/2016 11:09 AM, Naoto Sato wrote:
> So this fix will replace those left-right quotation marks in those CJK 
> locales from locale-specific font to "alphabetic", right? I don't know 
> much about the history (and personally I am fine with the fix), but 
> should we consult with the globalization team?
>
> Naoto
>
> On 3/17/16 12:54 PM, Phil Race wrote:
>> I think you are still waiting on i18n to reply here since the exclusion
>> ranges
>> are mainly used for ensuring that the glyphs come from the right font 
>> which
>> is mainly for locale reasons. If i18n see no problems then I am OK with
>> this.
>>
>> -phil.
>>
>> On 02/17/2016 05:01 AM, dmitry markov wrote:
>>> 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 masayoshi.okutsu at oracle.com  Sun Mar 20 04:11:26 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Sun, 20 Mar 2016 13:11:26 +0900
Subject: <i18n dev> [OpenJDK 2D-Dev] [9] Review request for 8073400:
 Some Monospaced logical fonts have a different width
In-Reply-To: <56EB0B71.8090000@oracle.com>
References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com>
	<56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com>
Message-ID: <56EE22EE.8070803@oracle.com>

The fix looks Okay to me. But there should be a regression test for this 
particular case? I wonder if we can have a test case to verify width(s) 
of monospaced glyphs.

Masayoshi


On 3/18/2016 4:54 AM, Phil Race wrote:
> I think you are still waiting on i18n to reply here since the 
> exclusion ranges
> are mainly used for ensuring that the glyphs come from the right font 
> which
> is mainly for locale reasons. If i18n see no problems then I am OK 
> with this.
>
> -phil.
>
> On 02/17/2016 05:01 AM, dmitry markov wrote:
>> 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 dmitry.markov at oracle.com  Mon Mar 21 07:56:05 2016
From: dmitry.markov at oracle.com (dmitry markov)
Date: Mon, 21 Mar 2016 10:56:05 +0300
Subject: <i18n dev> [OpenJDK 2D-Dev] [9] Review request for 8073400:
 Some Monospaced logical fonts have a different width
In-Reply-To: <56EE22EE.8070803@oracle.com>
References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com>
	<56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com>
	<56EE22EE.8070803@oracle.com>
Message-ID: <56EFA915.8010700@oracle.com>

Hello,
Thank you very much for the review.

I added a simple test for the fix. Please find the updated webrev here: 
http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.01/
Could you take a look at it, please?

thank you in advance,
Dmitry
On 20/03/2016 07:11, Masayoshi Okutsu wrote:
> The fix looks Okay to me. But there should be a regression test for 
> this particular case? I wonder if we can have a test case to verify 
> width(s) of monospaced glyphs.
>
> Masayoshi
>
>
> On 3/18/2016 4:54 AM, Phil Race wrote:
>> I think you are still waiting on i18n to reply here since the 
>> exclusion ranges
>> are mainly used for ensuring that the glyphs come from the right font 
>> which
>> is mainly for locale reasons. If i18n see no problems then I am OK 
>> with this.
>>
>> -phil.
>>
>> On 02/17/2016 05:01 AM, dmitry markov wrote:
>>> 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 Roger.Riggs at Oracle.com  Tue Mar 22 19:48:44 2016
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 22 Mar 2016 15:48:44 -0400
Subject: <i18n dev> RFR: regex changes
In-Reply-To: <56EC5F76.4080106@oracle.com>
References: <56EC5F76.4080106@oracle.com>
Message-ID: <56F1A19C.7000509@Oracle.com>

Hi Sherman,

A few more comments,

Pattern.java:
  - 1782: typo: "deterministci"

  - 2176: commented out code?

  - 2667: indentation

  - 5660,5655: lambda syntax  use of simply "ch" is preferred over 
"(ch)" for single parameter lambdas
    and for consistency within the file.

PrintPattern.java needs the standard copyright text if it is going to be 
in the repo.

- 29: The Print(fmt, args...) method should follow the method naming 
convention. (initial lowercase)

IntHashSet:  does performance matter enough to warrant adding this extra 
code.

Roger



On 3/18/2016 4:05 PM, Xueming Shen wrote:
> Hi,
>
> There are couple regex related changes waiting for review. I have pull 
> them
> together here (with the notes) to make it easy to review.
>
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/
>
> (1) Exponential backtracking
>
> Note: 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking
>
> https://bugs.openjdk.java.net/browse/JDK-6328855
> https://bugs.openjdk.java.net/browse/JDK-6192895
> https://bugs.openjdk.java.net/browse/JDK-6345469
> https://bugs.openjdk.java.net/browse/JDK-6988218
> https://bugs.openjdk.java.net/browse/JDK-6693451
> https://bugs.openjdk.java.net/browse/JDK-7006761
> https://bugs.openjdk.java.net/browse/JDK-8140212
>
> (2) Anonymous class to lambda function cleanup
>
> Note: 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction
>
> https://bugs.openjdk.java.net/browse/JDK-8151481
> https://bugs.openjdk.java.net/browse/JDK-6609854
>
> (3) Canonical Equivalents
>
> Note: 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ
>
> https://bugs.openjdk.java.net/browse/JDK-4916384
> https://bugs.openjdk.java.net/browse/JDK-4867170
> https://bugs.openjdk.java.net/browse/JDK-6995635
> https://bugs.openjdk.java.net/browse/JDK-6728861
> https://bugs.openjdk.java.net/browse/JDK-6736245
> https://bugs.openjdk.java.net/browse/JDK-7080302
>
> Thanks
> Sherman


From xueming.shen at oracle.com  Tue Mar 22 20:23:36 2016
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 22 Mar 2016 13:23:36 -0700
Subject: <i18n dev> RFR: regex changes
In-Reply-To: <56F1A19C.7000509@Oracle.com>
References: <56EC5F76.4080106@oracle.com> <56F1A19C.7000509@Oracle.com>
Message-ID: <56F1A9C8.7060508@oracle.com>

Thanks Roger!

webrev has been updated accordingly. See comments below.

http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/

On 03/22/2016 12:48 PM, Roger Riggs wrote:
> Hi Sherman,
>
> A few more comments,
>
> Pattern.java:
>  - 1782: typo: "deterministci"
>
fixed.

>  - 2176: commented out code?
>
Yes, commented out for now. It helps the case below, which has "lots"
of ".*" lined up in a single patter. But I have not decided if it's worth the
potential cost of adding a "backtracking stopper" for each ".*". In most
this kind of cases, it gets slow, very slow, but still come back alive,
instead of a complete hangup.

             // 5014450    -> top level single greedy ...
             { "^\\s*sites\\[sites\\.length\\+\\+\\]\\s*=\\s*new\\s+Array\\(.*" +
               "\\s*//\\s*(\\d+).*" +
               "\\s*//\\s*([^-]+).*" +
               "\\s*//\\s*([^-]+).*" +
               "\\s*//\\s*([^-]+).*" +
               "/(?sui).*$",
               "\tsites[sites.length++] = new Array(\n" +
               "// 1079193366647 - creation time\n" +
               "// 1078902678663 1078852539723 1078753482632 0 0 0 0 0 0 0 0 0 0 0 - creation time last 14 days\n" +
               "// 0 1 0 0 0 0 0 0 0 0 0 0 0 0 - bad\n" +
               "// 0.0030 0.0080 0.01 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 -\n\n",
               false
            },

I would leave it for now. There is a bugid for it. So we can address it separately,
might with better tradeoff.

>  - 2667: indentation
>

fixed.

>  - 5660,5655: lambda syntax  use of simply "ch" is preferred over "(ch)" for single parameter lambdas
>    and for consistency within the file.
>
fixed.

> PrintPattern.java needs the standard copyright text if it is going to be in the repo.
>
fixed.

> - 29: The Print(fmt, args...) method should follow the method naming convention. (initial lowercase)
>
fixed.

> IntHashSet:  does performance matter enough to warrant adding this extra code.
>

The measurement I did suggests it's still worth adding such a small piece code, given
this one probably will be used for most of the greedy {}, with lots of raw "int" in and
out, without boxing, and much smaller footprint.

Thanks again,

Sherman



>
>
> On 3/18/2016 4:05 PM, Xueming Shen wrote:
>> Hi,
>>
>> There are couple regex related changes waiting for review. I have pull them
>> together here (with the notes) to make it easy to review.
>>
>> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/
>>
>> (1) Exponential backtracking
>>
>> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking
>>
>> https://bugs.openjdk.java.net/browse/JDK-6328855
>> https://bugs.openjdk.java.net/browse/JDK-6192895
>> https://bugs.openjdk.java.net/browse/JDK-6345469
>> https://bugs.openjdk.java.net/browse/JDK-6988218
>> https://bugs.openjdk.java.net/browse/JDK-6693451
>> https://bugs.openjdk.java.net/browse/JDK-7006761
>> https://bugs.openjdk.java.net/browse/JDK-8140212
>>
>> (2) Anonymous class to lambda function cleanup
>>
>> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction
>>
>> https://bugs.openjdk.java.net/browse/JDK-8151481
>> https://bugs.openjdk.java.net/browse/JDK-6609854
>>
>> (3) Canonical Equivalents
>>
>> Note: http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ
>>
>> https://bugs.openjdk.java.net/browse/JDK-4916384
>> https://bugs.openjdk.java.net/browse/JDK-4867170
>> https://bugs.openjdk.java.net/browse/JDK-6995635
>> https://bugs.openjdk.java.net/browse/JDK-6728861
>> https://bugs.openjdk.java.net/browse/JDK-6736245
>> https://bugs.openjdk.java.net/browse/JDK-7080302
>>
>> Thanks
>> Sherman
>


From masayoshi.okutsu at oracle.com  Wed Mar 23 13:51:49 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 23 Mar 2016 22:51:49 +0900
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016b
In-Reply-To: <2ac381e9-521e-468c-abc8-b3e7ce13b4f5@default>
References: <2ac381e9-521e-468c-abc8-b3e7ce13b4f5@default>
Message-ID: <56F29F75.9020102@oracle.com>

Sorry for this belated response.

I prefer to follow the tzdata abbreviations, like "+04". But that would 
require some major changes. An option would be not to define time zone 
names for the new zones with the +hh format.

Thanks,
Masayoshi

On 3/17/2016 4:38 AM, Ramanand Patil wrote:
> Hi all,
>
> Please review the latest TZDATA (tzdata2016b) integration to JDK9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>
> All the TimeZone related tests are passed after integration.
>
>   
>
> Please note that, as per the release notes: As a trial of a new system that needs less information to be made up, the new zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".
>
> Since this is a trial system, I have ignored this in the current patch which adds 3 new timezones. But I think it's worth discussing this new system along with this bug and get the experts opinion on this.
>
> Do you think that JDK should also follow these IANA timezone naming system for zone abbreviations in future ?  Will it be convenient to use such numeric time zone abbreviations ? (Also, it looks like the abbreviations similar to "+03/+04" will be used for the zones linked to the rule set with changing letters like: EST/EDT for US, MSK/MSD for RU, etc..).
>
>   
>
> Regards,
>
> Ramanand.
>
>   


From nishit.jain at oracle.com  Thu Mar 24 05:14:11 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 24 Mar 2016 10:44:11 +0530
Subject: <i18n dev> Review Request for JDK-7015696: The new currency symbols
 20B9 (INDIAN RUPEE), 20BA (TURKISH LIRA), 20BD (RUBLE SIGN) not displayed
Message-ID: <56F377A3.8070600@oracle.com>

Hello All,

Please review the following fix in "windows.fontconfig.properties"

Bug: https://bugs.openjdk.java.net/browse/JDK-7015696
Webrev: http://cr.openjdk.java.net/~rgoel/Nishit/7015696/webrev.00/


Fix: Removed the unicode value of three currency symbols i.e. 20B9, 
20BA, 20BD  from exclusion range


Regards,
Nishit Jain

From nishit.jain at oracle.com  Thu Mar 24 05:27:54 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 24 Mar 2016 10:57:54 +0530
Subject: <i18n dev> Review Request for JDK-8031992 : Add Kannada support to
	the JDK
Message-ID: <56F37ADA.5080903@oracle.com>

Hello All,

Please review the following fix in "windows.fontconfig.properties"

Bug: https://bugs.openjdk.java.net/browse/JDK-8031992
Webrev: http://cr.openjdk.java.net/~rgoel/Nishit/8031992/webrev.01/

Fix: Added Windows' Kannada font i.e. "Tunga" definition to the fontconfig

Regards,
Nishit jain

From masayoshi.okutsu at oracle.com  Thu Mar 24 06:18:23 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 24 Mar 2016 15:18:23 +0900
Subject: <i18n dev> [OpenJDK 2D-Dev] [9] Review request for 8073400:
 Some Monospaced logical fonts have a different width
In-Reply-To: <56EFA915.8010700@oracle.com>
References: <56977953.10604@oracle.com> <56BB9CAC.3050408@oracle.com>
	<56C46F35.6030107@oracle.com> <56EB0B71.8090000@oracle.com>
	<56EE22EE.8070803@oracle.com> <56EFA915.8010700@oracle.com>
Message-ID: <56F386AF.4040807@oracle.com>

Looks good to me.

Masayoshi

On 3/21/2016 4:56 PM, dmitry markov wrote:
> Hello,
> Thank you very much for the review.
>
> I added a simple test for the fix. Please find the updated webrev 
> here: http://cr.openjdk.java.net/~dmarkov/8073400/jdk9/webrev.01/
> Could you take a look at it, please?
>
> thank you in advance,
> Dmitry
> On 20/03/2016 07:11, Masayoshi Okutsu wrote:
>> The fix looks Okay to me. But there should be a regression test for 
>> this particular case? I wonder if we can have a test case to verify 
>> width(s) of monospaced glyphs.
>>
>> Masayoshi
>>
>>
>> On 3/18/2016 4:54 AM, Phil Race wrote:
>>> I think you are still waiting on i18n to reply here since the 
>>> exclusion ranges
>>> are mainly used for ensuring that the glyphs come from the right 
>>> font which
>>> is mainly for locale reasons. If i18n see no problems then I am OK 
>>> with this.
>>>
>>> -phil.
>>>
>>> On 02/17/2016 05:01 AM, dmitry markov wrote:
>>>> 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 rachna.goel at oracle.com  Thu Mar 24 08:06:25 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Thu, 24 Mar 2016 13:36:25 +0530
Subject: <i18n dev> Review Request for JDK-8145136 : Upgrade CLDR Locale Data
Message-ID: <56F3A001.5070807@oracle.com>

Hello all,

Please review the fix for JDK-8145136.

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

Webrev: http://cr.openjdk.java.net/~rgoel/cldr28/webrev.00/

Fix: Upgraded CLDR data from Version 27 to 28.
More information at : http://cldr.unicode.org/

-- 
Thanks,
Rachna


From yuka.kamiya at oracle.com  Fri Mar 25 05:27:13 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Fri, 25 Mar 2016 14:27:13 +0900
Subject: <i18n dev> Review Request for JDK-7015696: The new currency
 symbols 20B9 (INDIAN RUPEE), 20BA (TURKISH LIRA),
 20BD (RUBLE SIGN) not displayed
In-Reply-To: <56F377A3.8070600@oracle.com>
References: <56F377A3.8070600@oracle.com>
Message-ID: <56F4CC31.2040000@oracle.com>

Hi Nishit,

The fix looks good to me.

Thanks,
--
Yuka

On 2016/03/24 14:14, Nishit Jain wrote:
> Hello All,
>
> Please review the following fix in "windows.fontconfig.properties"
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7015696
> Webrev: http://cr.openjdk.java.net/~rgoel/Nishit/7015696/webrev.00/
>
>
> Fix: Removed the unicode value of three currency symbols i.e. 20B9, 
> 20BA, 20BD  from exclusion range
>
>
> Regards,
> Nishit Jain


From rachna.goel at oracle.com  Mon Mar 28 06:15:38 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Mon, 28 Mar 2016 11:45:38 +0530
Subject: <i18n dev> Review Request for JDK-8150432:
 java/util/Locale/LocaleProviders.sh failed on Win10.
Message-ID: <56F8CC0A.1010904@oracle.com>

Hi all,

Please review a small fix for JDK-8150432. Bug and proposed fix are 
located at below links respectively.


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

http://cr.openjdk.java.net/~rgoel/8150432/webrev/ 
<http://cr.openjdk.java.net/%7Ergoel/8150432/webrev/>

fix: updated new kernel version for Windows 10 host since Windows 10 
kernel version bumped to "10.0" from "6.4" in Windows 8.

-- 
Thanks,
Rachna


From masayoshi.okutsu at oracle.com  Mon Mar 28 06:27:24 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 28 Mar 2016 15:27:24 +0900
Subject: <i18n dev> Review Request for JDK-8150432:
 java/util/Locale/LocaleProviders.sh failed on Win10.
In-Reply-To: <56F8CC0A.1010904@oracle.com>
References: <56F8CC0A.1010904@oracle.com>
Message-ID: <56F8CECC.7060304@oracle.com>

Looks good to me.

Masayoshi

On 3/28/2016 3:15 PM, Rachna Goel wrote:
> Hi all,
>
> Please review a small fix for JDK-8150432. Bug and proposed fix are 
> located at below links respectively.
>
>
> https://bugs.openjdk.java.net/browse/JDK-8150432
>
> http://cr.openjdk.java.net/~rgoel/8150432/webrev/ 
> <http://cr.openjdk.java.net/%7Ergoel/8150432/webrev/>
>
> fix: updated new kernel version for Windows 10 host since Windows 10 
> kernel version bumped to "10.0" from "6.4" in Windows 8.
>


From ramanand.patil at oracle.com  Mon Mar 28 10:31:08 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 28 Mar 2016 03:31:08 -0700 (PDT)
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016b
In-Reply-To: <56F29F75.9020102@oracle.com>
References: <2ac381e9-521e-468c-abc8-b3e7ce13b4f5@default>
	<56F29F75.9020102@oracle.com>
Message-ID: <20d3c2a7-d2c1-455f-ac1d-a2d47d2ba5d0@default>

Hi Masayoshi,

Currently I have not defined the new TimeZoneNames with +hh format, instead I have defined them as per the earlier convention like:

+            {"Asia/Barnaul", new String[] {"Barnaul Time", "BAT",
+                                           "Barnaul Summer Time", "BAST",
+                                           "Barnaul Time", "BAT"}},

+            {"Europe/Astrakhan", new String[] {"Astrakhan Time", "ASTT",
+                                               "Astrakhan Summer Time", "ASTST",
+                                               "Astrakhan Time", "ASTT"}},

+            {"Europe/Ulyanovsk", new String[] {"Ulyanovsk Time", "ULT",
+                                               "Ulyanovsk Summer Time", "ULST",
+                                               "Ulyanovsk Time", "ULT"}},



Please let me know if this is fine.


Regards,
Ramanand.

-----Original Message-----
From: Masayoshi Okutsu 
Sent: Wednesday, March 23, 2016 7:22 PM
To: Ramanand Patil; i18n-dev at openjdk.java.net
Cc: core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8151876: (tz) Support tzdata2016b

Sorry for this belated response.

I prefer to follow the tzdata abbreviations, like "+04". But that would require some major changes. An option would be not to define time zone names for the new zones with the +hh format.

Thanks,
Masayoshi

On 3/17/2016 4:38 AM, Ramanand Patil wrote:
> Hi all,
>
> Please review the latest TZDATA (tzdata2016b) integration to JDK9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>
> All the TimeZone related tests are passed after integration.
>
>   
>
> Please note that, as per the release notes: As a trial of a new system that needs less information to be made up, the new zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".
>
> Since this is a trial system, I have ignored this in the current patch which adds 3 new timezones. But I think it's worth discussing this new system along with this bug and get the experts opinion on this.
>
> Do you think that JDK should also follow these IANA timezone naming system for zone abbreviations in future ?  Will it be convenient to use such numeric time zone abbreviations ? (Also, it looks like the abbreviations similar to "+03/+04" will be used for the zones linked to the rule set with changing letters like: EST/EDT for US, MSK/MSD for RU, etc..).
>
>   
>
> Regards,
>
> Ramanand.
>
>   


From masayoshi.okutsu at oracle.com  Mon Mar 28 13:19:39 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 28 Mar 2016 22:19:39 +0900
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016b
In-Reply-To: <20d3c2a7-d2c1-455f-ac1d-a2d47d2ba5d0@default>
References: <2ac381e9-521e-468c-abc8-b3e7ce13b4f5@default>
	<56F29F75.9020102@oracle.com>
	<20d3c2a7-d2c1-455f-ac1d-a2d47d2ba5d0@default>
Message-ID: <56F92F6B.4080107@oracle.com>

Hi Ramanand,

What I meant is to remove those new resources so that "GMT+hh:mm" is 
used for formatting. There may be some tests that require changes.

Thanks,
Masayoshi

On 3/28/2016 7:31 PM, Ramanand Patil wrote:
> Hi Masayoshi,
>
> Currently I have not defined the new TimeZoneNames with +hh format, instead I have defined them as per the earlier convention like:
>
> +            {"Asia/Barnaul", new String[] {"Barnaul Time", "BAT",
> +                                           "Barnaul Summer Time", "BAST",
> +                                           "Barnaul Time", "BAT"}},
>
> +            {"Europe/Astrakhan", new String[] {"Astrakhan Time", "ASTT",
> +                                               "Astrakhan Summer Time", "ASTST",
> +                                               "Astrakhan Time", "ASTT"}},
>
> +            {"Europe/Ulyanovsk", new String[] {"Ulyanovsk Time", "ULT",
> +                                               "Ulyanovsk Summer Time", "ULST",
> +                                               "Ulyanovsk Time", "ULT"}},
>
>
>
> Please let me know if this is fine.
>
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Masayoshi Okutsu
> Sent: Wednesday, March 23, 2016 7:22 PM
> To: Ramanand Patil; i18n-dev at openjdk.java.net
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8151876: (tz) Support tzdata2016b
>
> Sorry for this belated response.
>
> I prefer to follow the tzdata abbreviations, like "+04". But that would require some major changes. An option would be not to define time zone names for the new zones with the +hh format.
>
> Thanks,
> Masayoshi
>
> On 3/17/2016 4:38 AM, Ramanand Patil wrote:
>> Hi all,
>>
>> Please review the latest TZDATA (tzdata2016b) integration to JDK9.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>>
>> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>>
>> All the TimeZone related tests are passed after integration.
>>
>>    
>>
>> Please note that, as per the release notes: As a trial of a new system that needs less information to be made up, the new zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".
>>
>> Since this is a trial system, I have ignored this in the current patch which adds 3 new timezones. But I think it's worth discussing this new system along with this bug and get the experts opinion on this.
>>
>> Do you think that JDK should also follow these IANA timezone naming system for zone abbreviations in future ?  Will it be convenient to use such numeric time zone abbreviations ? (Also, it looks like the abbreviations similar to "+03/+04" will be used for the zones linked to the rule set with changing letters like: EST/EDT for US, MSK/MSD for RU, etc..).
>>
>>    
>>
>> Regards,
>>
>> Ramanand.
>>
>>    


From amy.lu at oracle.com  Tue Mar 29 02:33:38 2016
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 29 Mar 2016 10:33:38 +0800
Subject: <i18n dev> JDK 9 RFR of JDK-8152873:
 java/util/Locale/LocaleProviders.sh fails on several platforms
Message-ID: <56F9E982.5000205@oracle.com>

java/util/Locale/LocaleProviders.sh starts failing after JDK-8150432, 
there's simple issue in JDK-8150432.
Please review this quick fix.

bug: https://bugs.openjdk.java.net/browse/JDK-8152873
webrev: http://cr.openjdk.java.net/~amlu/8152873/webrev.00/

Thanks,
Amy


--- old/test/java/util/Locale/LocaleProviders.sh	2016-03-29 10:15:10.000000000 +0800
+++ new/test/java/util/Locale/LocaleProviders.sh	2016-03-29 10:15:10.000000000 +0800
@@ -25,7 +25,7 @@
  # @test
  # @bug 6336885 7196799 7197573 7198834 8000245 8000615 8001440 8008577
  #      8010666 8013086 8013233 8013903 8015960 8028771 8054482 8062006
-       8150432
+#      8150432
  # @summary tests for "java.locale.providers" system property
  # @modules java.base/sun.util.locale
  #          java.base/sun.util.locale.provider




From joe.darcy at oracle.com  Tue Mar 29 02:44:17 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 28 Mar 2016 19:44:17 -0700
Subject: <i18n dev> JDK 9 RFR of JDK-8152873:
 java/util/Locale/LocaleProviders.sh fails on several platforms
In-Reply-To: <56F9E982.5000205@oracle.com>
References: <56F9E982.5000205@oracle.com>
Message-ID: <56F9EC01.4070701@oracle.com>

Looks fine; thanks Amy,

-Joe

On 3/28/2016 7:33 PM, Amy Lu wrote:
> java/util/Locale/LocaleProviders.sh starts failing after JDK-8150432, 
> there's simple issue in JDK-8150432.
> Please review this quick fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8152873
> webrev: http://cr.openjdk.java.net/~amlu/8152873/webrev.00/
>
> Thanks,
> Amy
>
>
> --- old/test/java/util/Locale/LocaleProviders.sh    2016-03-29 
> 10:15:10.000000000 +0800
> +++ new/test/java/util/Locale/LocaleProviders.sh    2016-03-29 
> 10:15:10.000000000 +0800
> @@ -25,7 +25,7 @@
>  # @test
>  # @bug 6336885 7196799 7197573 7198834 8000245 8000615 8001440 8008577
>  #      8010666 8013086 8013233 8013903 8015960 8028771 8054482 8062006
> -       8150432
> +#      8150432
>  # @summary tests for "java.locale.providers" system property
>  # @modules java.base/sun.util.locale
>  #          java.base/sun.util.locale.provider
>
>
>


From ramanand.patil at oracle.com  Tue Mar 29 04:34:53 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 28 Mar 2016 21:34:53 -0700 (PDT)
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016b
In-Reply-To: <56F92F6B.4080107@oracle.com>
References: <2ac381e9-521e-468c-abc8-b3e7ce13b4f5@default>
	<56F29F75.9020102@oracle.com>
	<20d3c2a7-d2c1-455f-ac1d-a2d47d2ba5d0@default>
	<56F92F6B.4080107@oracle.com>
Message-ID: <f280341c-71ee-416e-bdc9-008ba8f5a38e@default>

Hi Masayoshi,

Thank you for clarification.

Since, the tzdata2016c is already released, I will update the this bug and send a new review request to include both tzdata2016b and tzdata2016c.


Regards,
Ramanand.

-----Original Message-----
From: Masayoshi Okutsu 
Sent: Monday, March 28, 2016 6:50 PM
To: Ramanand Patil; i18n-dev at openjdk.java.net
Cc: core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8151876: (tz) Support tzdata2016b

Hi Ramanand,

What I meant is to remove those new resources so that "GMT+hh:mm" is used for formatting. There may be some tests that require changes.

Thanks,
Masayoshi

On 3/28/2016 7:31 PM, Ramanand Patil wrote:
> Hi Masayoshi,
>
> Currently I have not defined the new TimeZoneNames with +hh format, instead I have defined them as per the earlier convention like:
>
> +            {"Asia/Barnaul", new String[] {"Barnaul Time", "BAT",
> +                                           "Barnaul Summer Time", "BAST",
> +                                           "Barnaul Time", "BAT"}},
>
> +            {"Europe/Astrakhan", new String[] {"Astrakhan Time", "ASTT",
> +                                               "Astrakhan Summer Time", "ASTST",
> +                                               "Astrakhan Time", 
> + "ASTT"}},
>
> +            {"Europe/Ulyanovsk", new String[] {"Ulyanovsk Time", "ULT",
> +                                               "Ulyanovsk Summer Time", "ULST",
> +                                               "Ulyanovsk Time", 
> + "ULT"}},
>
>
>
> Please let me know if this is fine.
>
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Masayoshi Okutsu
> Sent: Wednesday, March 23, 2016 7:22 PM
> To: Ramanand Patil; i18n-dev at openjdk.java.net
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8151876: (tz) Support tzdata2016b
>
> Sorry for this belated response.
>
> I prefer to follow the tzdata abbreviations, like "+04". But that would require some major changes. An option would be not to define time zone names for the new zones with the +hh format.
>
> Thanks,
> Masayoshi
>
> On 3/17/2016 4:38 AM, Ramanand Patil wrote:
>> Hi all,
>>
>> Please review the latest TZDATA (tzdata2016b) integration to JDK9.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>>
>> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>>
>> All the TimeZone related tests are passed after integration.
>>
>>    
>>
>> Please note that, as per the release notes: As a trial of a new system that needs less information to be made up, the new zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".
>>
>> Since this is a trial system, I have ignored this in the current patch which adds 3 new timezones. But I think it's worth discussing this new system along with this bug and get the experts opinion on this.
>>
>> Do you think that JDK should also follow these IANA timezone naming system for zone abbreviations in future ?  Will it be convenient to use such numeric time zone abbreviations ? (Also, it looks like the abbreviations similar to "+03/+04" will be used for the zones linked to the rule set with changing letters like: EST/EDT for US, MSK/MSD for RU, etc..).
>>
>>    
>>
>> Regards,
>>
>> Ramanand.
>>
>>    


From masayoshi.okutsu at oracle.com  Tue Mar 29 07:55:21 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 29 Mar 2016 16:55:21 +0900
Subject: <i18n dev> RFR: 8152077: (cal) Calendar.roll does not always roll
 the hours during daylight savings changes
Message-ID: <56FA34E9.3000602@oracle.com>

Hello,

Please review the fix for JDK-8152077. There's a bug in the roll method 
around the standard/daylight saving time transitions. I've changed the 
implementation to perform the "roll" operation based on the wall-clock 
time rather than the UTC time (the offset from the Epoch).

Issue:
https://bugs.openjdk.java.net/browse/JDK-8152077

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8152077/webrev.00/

Thanks,
Masayoshi


From yuka.kamiya at oracle.com  Tue Mar 29 08:50:20 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Tue, 29 Mar 2016 17:50:20 +0900
Subject: <i18n dev> RFR: 8152077: (cal) Calendar.roll does not always
 roll the hours during daylight savings changes
In-Reply-To: <56FA34E9.3000602@oracle.com>
References: <56FA34E9.3000602@oracle.com>
Message-ID: <56FA41CC.2080100@oracle.com>

Hi,

The fix looks good to me.

Thanks,
--
Yuka

On 2016/03/29 16:55, Masayoshi Okutsu wrote:
> Hello,
>
> Please review the fix for JDK-8152077. There's a bug in the roll 
> method around the standard/daylight saving time transitions. I've 
> changed the implementation to perform the "roll" operation based on 
> the wall-clock time rather than the UTC time (the offset from the Epoch).
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8152077
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8152077/webrev.00/
>
> Thanks,
> Masayoshi
>


From masayoshi.okutsu at oracle.com  Wed Mar 30 15:40:00 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 31 Mar 2016 00:40:00 +0900
Subject: <i18n dev> RFR: 8152817: Locale data loading fails silently when
 running with a security manager
Message-ID: <56FBF350.1030500@oracle.com>

Hello,

Please review the fix for JDK-8152817. The fix is to load locale data 
from its own module without calling 
ResourceBundleProviderSupport.loadResourceBundle.

I changed the synopsis of the JBS issue because it's a general issue of 
loading locale data under a security manager, and the regression test 
uses DateFormatSymbols.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8152817
Webrev:
http://cr.openjdk.java.net/~okutsu/9/8152817/webrev.00/

Thanks,
Masayoshi


From mandy.chung at oracle.com  Wed Mar 30 15:48:46 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 30 Mar 2016 08:48:46 -0700
Subject: <i18n dev> RFR: 8152817: Locale data loading fails silently
	when running with a security manager
In-Reply-To: <56FBF350.1030500@oracle.com>
References: <56FBF350.1030500@oracle.com>
Message-ID: <A8395154-4A23-4A5D-A227-F6B9DA78B59B@oracle.com>


> On Mar 30, 2016, at 8:40 AM, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
> 
> Hello,
> 
> Please review the fix for JDK-8152817. The fix is to load locale data from its own module without calling ResourceBundleProviderSupport.loadResourceBundle.
> 
> I changed the synopsis of the JBS issue because it's a general issue of loading locale data under a security manager, and the regression test uses DateFormatSymbols.
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8152817
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8152817/webrev.00/


The patch looks fine.  It makes sense to have its own copy of the utility method to load a module-private class.

You can call Class::newInstance instead of Constructor::newInstance to make the code much simpler. Class::newInstance doesn?t throw InvocationTargetException and no need to have uncheckedThrow.

Mandy

From Alan.Bateman at oracle.com  Wed Mar 30 15:54:49 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 30 Mar 2016 16:54:49 +0100
Subject: <i18n dev> RFR: 8152817: Locale data loading fails silently
 when running with a security manager
In-Reply-To: <A8395154-4A23-4A5D-A227-F6B9DA78B59B@oracle.com>
References: <56FBF350.1030500@oracle.com>
	<A8395154-4A23-4A5D-A227-F6B9DA78B59B@oracle.com>
Message-ID: <56FBF6C9.2090308@oracle.com>

On 30/03/2016 16:48, Mandy Chung wrote:
>> On Mar 30, 2016, at 8:40 AM, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
>>
>> Hello,
>>
>> Please review the fix for JDK-8152817. The fix is to load locale data from its own module without calling ResourceBundleProviderSupport.loadResourceBundle.
>>
>> I changed the synopsis of the JBS issue because it's a general issue of loading locale data under a security manager, and the regression test uses DateFormatSymbols.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8152817
>> Webrev:
>> http://cr.openjdk.java.net/~okutsu/9/8152817/webrev.00/
>
> The patch looks fine.  It makes sense to have its own copy of the utility method to load a module-private class.
I agree. There's another usage in SupplementaryLocaleDataProvider and I 
wonder if we have an issue there too.


>
> You can call Class::newInstance instead of Constructor::newInstance to make the code much simpler. Class::newInstance doesn?t throw InvocationTargetException and no need to have uncheckedThrow.
>
I was wondering about that too.

-Alan

From mandy.chung at oracle.com  Wed Mar 30 16:14:58 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 30 Mar 2016 09:14:58 -0700
Subject: <i18n dev> RFR: 8152817: Locale data loading fails silently
	when running with a security manager
In-Reply-To: <56FBF6C9.2090308@oracle.com>
References: <56FBF350.1030500@oracle.com>
	<A8395154-4A23-4A5D-A227-F6B9DA78B59B@oracle.com>
	<56FBF6C9.2090308@oracle.com>
Message-ID: <CCDAC8AD-D9C8-4B58-8DBA-76F72F39F0B0@oracle.com>


> On Mar 30, 2016, at 8:54 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> On 30/03/2016 16:48, Mandy Chung wrote:
>>> On Mar 30, 2016, at 8:40 AM, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
>>> 
>>> Hello,
>>> 
>>> Please review the fix for JDK-8152817. The fix is to load locale data from its own module without calling ResourceBundleProviderSupport.loadResourceBundle.
>>> 
>>> I changed the synopsis of the JBS issue because it's a general issue of loading locale data under a security manager, and the regression test uses DateFormatSymbols.
>>> 
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8152817
>>> Webrev:
>>> http://cr.openjdk.java.net/~okutsu/9/8152817/webrev.00/
>> 
>> The patch looks fine.  It makes sense to have its own copy of the utility method to load a module-private class.
> I agree. There's another usage in SupplementaryLocaleDataProvider and I wonder if we have an issue there too.
> 
> 

Good catch.  SupplementaryLocaleDataProvider needs to be fixed. 

Mandy


From naoto.sato at oracle.com  Wed Mar 30 17:03:27 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 30 Mar 2016 10:03:27 -0700
Subject: <i18n dev> [9] RFR: 8153041: Remove unused redundant parameter in
	CLDRConverter
Message-ID: <56FC06DF.30606@oracle.com>

Hello,

Please review this simple fix to the subject bug:

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

The fix is located at:

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

Naoto

From masayoshi.okutsu at oracle.com  Wed Mar 30 23:56:00 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 31 Mar 2016 08:56:00 +0900
Subject: <i18n dev> RFR: 8152817: Locale data loading fails silently
 when running with a security manager
In-Reply-To: <56FBF6C9.2090308@oracle.com>
References: <56FBF350.1030500@oracle.com>
	<A8395154-4A23-4A5D-A227-F6B9DA78B59B@oracle.com>
	<56FBF6C9.2090308@oracle.com>
Message-ID: <56FC6790.5010700@oracle.com>

On 3/31/2016 12:54 AM, Alan Bateman wrote:
> On 30/03/2016 16:48, Mandy Chung wrote:
>>> On Mar 30, 2016, at 8:40 AM, Masayoshi Okutsu 
>>> <masayoshi.okutsu at oracle.com> wrote:
>>>
>>> Hello,
>>>
>>> Please review the fix for JDK-8152817. The fix is to load locale 
>>> data from its own module without calling 
>>> ResourceBundleProviderSupport.loadResourceBundle.
>>>
>>> I changed the synopsis of the JBS issue because it's a general issue 
>>> of loading locale data under a security manager, and the regression 
>>> test uses DateFormatSymbols.
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8152817
>>> Webrev:
>>> http://cr.openjdk.java.net/~okutsu/9/8152817/webrev.00/
>>
>> The patch looks fine.  It makes sense to have its own copy of the 
>> utility method to load a module-private class.
> I agree. There's another usage in SupplementaryLocaleDataProvider and 
> I wonder if we have an issue there too.

Thank you for catching this.

>
>
>>
>> You can call Class::newInstance instead of Constructor::newInstance 
>> to make the code much simpler. Class::newInstance doesn?t throw 
>> InvocationTargetException and no need to have uncheckedThrow.
>>
> I was wondering about that too.

My initial fix called Class::newInstance. But I thought 
Constructor::newInstance would be better after reading the API doc. I 
will change it back to call Class::newInstance.

Thanks,
Masayoshi


From masayoshi.okutsu at oracle.com  Thu Mar 31 09:29:58 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 31 Mar 2016 18:29:58 +0900
Subject: <i18n dev> RFR: 8152817: Locale data loading fails silently
 when running with a security manager
In-Reply-To: <56FC6790.5010700@oracle.com>
References: <56FBF350.1030500@oracle.com>
	<A8395154-4A23-4A5D-A227-F6B9DA78B59B@oracle.com>
	<56FBF6C9.2090308@oracle.com> <56FC6790.5010700@oracle.com>
Message-ID: <56FCEE16.6020306@oracle.com>

Webrev has been updated. I realized that some code which was for loading 
resource bundles in both java.base and jdk.localedata remained. The 
providers are no longer used for loading resource bundles in java.base. 
The code was removed.

http://cr.openjdk.java.net/~okutsu/9/8152817/webrev.01/

Thanks,
Masayoshi

On 3/31/2016 8:56 AM, Masayoshi Okutsu wrote:
> On 3/31/2016 12:54 AM, Alan Bateman wrote:
>> On 30/03/2016 16:48, Mandy Chung wrote:
>>>> On Mar 30, 2016, at 8:40 AM, Masayoshi Okutsu 
>>>> <masayoshi.okutsu at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Please review the fix for JDK-8152817. The fix is to load locale 
>>>> data from its own module without calling 
>>>> ResourceBundleProviderSupport.loadResourceBundle.
>>>>
>>>> I changed the synopsis of the JBS issue because it's a general 
>>>> issue of loading locale data under a security manager, and the 
>>>> regression test uses DateFormatSymbols.
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8152817
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~okutsu/9/8152817/webrev.00/
>>>
>>> The patch looks fine.  It makes sense to have its own copy of the 
>>> utility method to load a module-private class.
>> I agree. There's another usage in SupplementaryLocaleDataProvider and 
>> I wonder if we have an issue there too.
>
> Thank you for catching this.
>
>>
>>
>>>
>>> You can call Class::newInstance instead of Constructor::newInstance 
>>> to make the code much simpler. Class::newInstance doesn?t throw 
>>> InvocationTargetException and no need to have uncheckedThrow.
>>>
>> I was wondering about that too.
>
> My initial fix called Class::newInstance. But I thought 
> Constructor::newInstance would be better after reading the API doc. I 
> will change it back to call Class::newInstance.
>
> Thanks,
> Masayoshi
>


From Alan.Bateman at oracle.com  Thu Mar 31 13:05:02 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 31 Mar 2016 14:05:02 +0100
Subject: <i18n dev> RFR: 8152817: Locale data loading fails silently
 when running with a security manager
In-Reply-To: <56FCEE16.6020306@oracle.com>
References: <56FBF350.1030500@oracle.com>
	<A8395154-4A23-4A5D-A227-F6B9DA78B59B@oracle.com>
	<56FBF6C9.2090308@oracle.com> <56FC6790.5010700@oracle.com>
	<56FCEE16.6020306@oracle.com>
Message-ID: <56FD207E.1000101@oracle.com>



On 31/03/2016 10:29, Masayoshi Okutsu wrote:
> Webrev has been updated. I realized that some code which was for 
> loading resource bundles in both java.base and jdk.localedata 
> remained. The providers are no longer used for loading resource 
> bundles in java.base. The code was removed.
>
> http://cr.openjdk.java.net/~okutsu/9/8152817/webrev.01/
This looks okay to me.

-Alan

From mandy.chung at oracle.com  Thu Mar 31 21:50:20 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 31 Mar 2016 14:50:20 -0700
Subject: <i18n dev> RFR: 8152817: Locale data loading fails silently
	when running with a security manager
In-Reply-To: <56FCEE16.6020306@oracle.com>
References: <56FBF350.1030500@oracle.com>
	<A8395154-4A23-4A5D-A227-F6B9DA78B59B@oracle.com>
	<56FBF6C9.2090308@oracle.com> <56FC6790.5010700@oracle.com>
	<56FCEE16.6020306@oracle.com>
Message-ID: <8EF70E76-1C07-4A3F-80C2-E612F5625BD0@oracle.com>


> On Mar 31, 2016, at 2:29 AM, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
> 
> Webrev has been updated. I realized that some code which was for loading resource bundles in both java.base and jdk.localedata remained. The providers are no longer used for loading resource bundles in java.base. The code was removed.
> 
> http://cr.openjdk.java.net/~okutsu/9/8152817/webrev.01/

Looks fine.

Mandy