From aleksej.efimov at oracle.com Thu Jun 4 15:47:42 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 04 Jun 2015 18:47:42 +0300 Subject: RFR: 8080774: DateFormat for Singapore/English locale (en_SG) is M/d/yy instead of d/M/yy Message-ID: <5570731E.5020104@oracle.com> Hi, Please review an English Singapore (en_SG) date formats fix [2] in JRE locale provider. According to the latest CLDR data (27.0.1) [3] day should precede month in all date formats. JRE locale provider has different formats that should be fixed accordingly - changes in FormatData_en_SG.java. Existing test case was updated with new date formats for en_SG locale - test/sun/text/resources/LocaleData changes. New regression test was also created for this issue - it tests the JRE locale provider and en_SG locale date formats. When jdk9 will start use CLDR as a default locale data provider [4] this test might be useful to test the old provider. But the addition of this test to test repository is a topic for discussion. Thanks, Aleksej [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8080774 [2] Webrev: http://cr.openjdk.java.net/~aefimov/8080774/9/00/ [3] CLDR data (search for en_SG): http://www.unicode.org/cldr/charts/27/by_type/date_&_time.generic.html [4] JEP 252: Use CLDR Locale Data by Default: http://openjdk.java.net/jeps/252 From naoto.sato at oracle.com Thu Jun 4 20:10:39 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 04 Jun 2015 13:10:39 -0700 Subject: RFR: 8080774: DateFormat for Singapore/English locale (en_SG) is M/d/yy instead of d/M/yy In-Reply-To: <5570731E.5020104@oracle.com> References: <5570731E.5020104@oracle.com> Message-ID: <5570B0BF.7070107@oracle.com> Hi Aleksej, I'd move the line 5423 in LocaleData (new) up before your change lines as it was meant for the original 6498742 regression test. Other than that it looks good to me. Naoto On 6/4/15 8:47 AM, Aleksej Efimov wrote: > Hi, > > Please review an English Singapore (en_SG) date formats fix [2] in JRE > locale provider. > According to the latest CLDR data (27.0.1) [3] day should precede month > in all date formats. > JRE locale provider has different formats that should be fixed > accordingly - changes in FormatData_en_SG.java. > Existing test case was updated with new date formats for en_SG locale - > test/sun/text/resources/LocaleData changes. > New regression test was also created for this issue - it tests the JRE > locale provider and en_SG locale date formats. When jdk9 will start use > CLDR as a default locale data provider [4] this test might be useful to > test the old provider. But the addition of this test to test repository > is a topic for discussion. > > Thanks, > Aleksej > > [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8080774 > [2] Webrev: http://cr.openjdk.java.net/~aefimov/8080774/9/00/ > [3] CLDR data (search for en_SG): > http://www.unicode.org/cldr/charts/27/by_type/date_&_time.generic.html > [4] JEP 252: Use CLDR Locale Data by Default: > http://openjdk.java.net/jeps/252 From y.umaoka at gmail.com Fri Jun 5 15:31:25 2015 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 05 Jun 2015 11:31:25 -0400 Subject: DateFormatSymbols triggers this.clone() in the constructor Message-ID: <5571C0CD.6080801@gmail.com> Hi folks, ICU4J implements Java locale service provider interface. I recently received a problem report from our customer. When they upgraded Java version to 8, the provider implementation stopped working because of NPE thrown by our custom DateFormatSymbols subclass. I dug into the problem and found that DateFormatSymbols caches its own instance in the constructor. Our subclass implementation expects a field is always initialized to non-null in the constructor. However, clone() method is called for the super class's constructor, the field is not yet initialized at the point. It looks adding 'null' for the field in clone() method would resolve the immediate problem, but I'm not comfortable that DateFormatSymbols implementation cache a premature instance of my own subclass. If any methods overridden by my own subclass is called on a premature instance, it might cause another issue. Anyway, I filed a bug in the Java bug database with the description below. For meanwhile, adding simple 'null' check in our code would suffice. But I would like to hear Java i18n team's opinion about this issue. Thanks, Yoshito --------------------------- To implement my own locale service provider, I have a class extending java.text.DateFormatSymbols. My custom subclass's constructor implicitly invokes the no-args constructor in java.text.DateFormatSymbols. The constructor calls a private method - initializeData(Locale). It looks the implementation was updated in Java 8 and initializeData is now trying to cache an instance of DateFormatSymbols at the end and calls this.clone(). In my own subclass implements clone() method, which copies a field initialized by a constructor in the class. For example, =============== public class MyDateFormatSymbols extends DateFormatSymbols { private final Foo foo; public MyDateFormatSymbols(Foo foo) { if (foo == null) { this.foo = new Foo(); } else { this.foo = foo; } } @Override public Object clone() { MyDateFormatSymbols mdfs = (MyDateFormatSymbols)super.clone(); mdfs.foo = this.foo.clone(); } } =============== When the constructor MyDateFormatSymbols(Foo) is called, it triggers no-args constructor of the super class - DateFormatSymbols() first. As I explained earlier, Java 8 implementation calls this.clone() in DateFormatSymbpls.initializeData(Locale). At that point, the field foo in my class is not yet initialized, so this.foo.clone() will throw NullPointerException. My own code expects the field 'foo' is always non-null. I could change clone() to check if this.foo is null or not, but I cannot control cached 'premature' instance held by Java DateFormatSymbols. At this moment, it looks the cache is only used for copying field values maintained by DateFormaSymbols itself and never call a method. So, even 'premature' instance of my own subclass instance is referenced by DateFormatSymbols, it won't cause any problems. However, if the Java's implementation is changed to call any DateFormatSymbols method overridden by my own subclass, it may not work (because my subclass expects the field foo is non-null). Such code above did not have any problems with earlier Java releases (Java 6 / 7). In my opinion, this.clone() should not be called in DateFormatSymbols initialization code. Instead, it should create a private container class for these symbols, and cache the object, not DateFormatSymbols itself. From y.umaoka at gmail.com Fri Jun 5 16:59:22 2015 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 05 Jun 2015 12:59:22 -0400 Subject: DateFormatSymbols triggers this.clone() in the constructor In-Reply-To: <5571C0CD.6080801@gmail.com> References: <5571C0CD.6080801@gmail.com> Message-ID: <5571D56A.1090709@gmail.com> On 6/5/2015 11:31 AM, Yoshito Umaoka wrote: > @Override > public Object clone() { > MyDateFormatSymbols mdfs = (MyDateFormatSymbols)super.clone(); > mdfs.foo = this.foo.clone(); > } Minor correction - "return mdfs;" was missing in the pseudo code above. -Yoshito From naoto.sato at oracle.com Fri Jun 5 21:53:26 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 05 Jun 2015 14:53:26 -0700 Subject: DateFormatSymbols triggers this.clone() in the constructor In-Reply-To: <5571C0CD.6080801@gmail.com> References: <5571C0CD.6080801@gmail.com> Message-ID: <55721A56.90107@oracle.com> Umaoka-san, I believe the cloning is needed to return the defensive copy, otherwise an app can mutate the state of the DateFormatSymbols for other apps. One solution could be to not cache the instance if its from SPI, but apparently that will affect the performance. I don't see anything wrong to check if foo is null or not in clone(), since it's a private property to the provider. Naoto On 6/5/15 8:31 AM, Yoshito Umaoka wrote: > Hi folks, > > ICU4J implements Java locale service provider interface. I recently > received a problem report from our customer. When they upgraded Java > version to 8, the provider implementation stopped working because of NPE > thrown by our custom DateFormatSymbols subclass. I dug into the problem > and found that DateFormatSymbols caches its own instance in the > constructor. Our subclass implementation expects a field is always > initialized to non-null in the constructor. However, clone() method is > called for the super class's constructor, the field is not yet > initialized at the point. > > It looks adding 'null' for the field in clone() method would resolve the > immediate problem, but I'm not comfortable that DateFormatSymbols > implementation cache a premature instance of my own subclass. If any > methods overridden by my own subclass is called on a premature instance, > it might cause another issue. > > Anyway, I filed a bug in the Java bug database with the description > below. For meanwhile, adding simple 'null' check in our code would > suffice. But I would like to hear Java i18n team's opinion about this > issue. > > Thanks, > Yoshito > > > --------------------------- > To implement my own locale service provider, I have a class extending > java.text.DateFormatSymbols. My custom subclass's constructor implicitly > invokes the no-args constructor in java.text.DateFormatSymbols. The > constructor calls a private method - initializeData(Locale). > > It looks the implementation was updated in Java 8 and initializeData is > now trying to cache an instance of DateFormatSymbols at the end and > calls this.clone(). > > In my own subclass implements clone() method, which copies a field > initialized by a constructor in the class. For example, > > =============== > public class MyDateFormatSymbols extends DateFormatSymbols { > private final Foo foo; > > public MyDateFormatSymbols(Foo foo) { > if (foo == null) { > this.foo = new Foo(); > } else { > this.foo = foo; > } > } > > @Override > public Object clone() { > MyDateFormatSymbols mdfs = (MyDateFormatSymbols)super.clone(); > mdfs.foo = this.foo.clone(); > } > } > =============== > > When the constructor MyDateFormatSymbols(Foo) is called, it triggers > no-args constructor of the super class - DateFormatSymbols() first. As I > explained earlier, Java 8 implementation calls this.clone() in > DateFormatSymbpls.initializeData(Locale). At that point, the field foo > in my class is not yet initialized, so this.foo.clone() will throw > NullPointerException. > > My own code expects the field 'foo' is always non-null. I could change > clone() to check if this.foo is null or not, but I cannot control cached > 'premature' instance held by Java DateFormatSymbols. At this moment, it > looks the cache is only used for copying field values maintained by > DateFormaSymbols itself and never call a method. So, even 'premature' > instance of my own subclass instance is referenced by DateFormatSymbols, > it won't cause any problems. However, if the Java's implementation is > changed to call any DateFormatSymbols method overridden by my own > subclass, it may not work (because my subclass expects the field foo is > non-null). > > Such code above did not have any problems with earlier Java releases > (Java 6 / 7). > > In my opinion, this.clone() should not be called in DateFormatSymbols > initialization code. Instead, it should create a private container class > for these symbols, and cache the object, not DateFormatSymbols itself. From y.umaoka at gmail.com Sat Jun 6 03:22:27 2015 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 05 Jun 2015 23:22:27 -0400 Subject: DateFormatSymbols triggers this.clone() in the constructor In-Reply-To: <55721A56.90107@oracle.com> References: <5571C0CD.6080801@gmail.com> <55721A56.90107@oracle.com> Message-ID: <55726773.8050405@gmail.com> Sato-san, Yes, it's not thing wrong to check null in the clone() method, and that's what I did to avoid this problem. But what we can do there is to skip cloning the field in our code only. With the current Java implementation, I'm pretty sure that it won't cause any actual problem, because Java implementation does not call any methods on the cached copy. The implementation only reads previously initialized symbols (such as weekday name, month names) by directly accessing the fields. However, if the implementation is changed in future and calls any DateFormatSymbols' public method, our subclass won't work because our class overrides these methods and expects the field (which is supposed to be initialized by our class's constructor) is null. I'm not suggesting that Java DateFormatSymbols should not utilize a cache storing symbols initialized from resource bundles. My point is - caching an instance of DateFormatSymbols itself could be dangerous because of the reason I explained above. I think the right thing to do is to create a private class object holding these symbols (this can be a singleton per Locale) separate from DateFormatSymbols - and DateFormatSymbols constructor just copy the field to a new DateFormatSymbols 2nd time. For example, creating a private class: private static class SymbolsCacheEntry { String eras[]; String months[]; .... String patternChars; .... } Then actual locale data is once loaded into SymbolsCacheEntry - and cached. When DateFormatSymbols constructor is called 2nd time, "copyMembers()" copies field values from an instance of SymbolsCacheEntry (instead of cached DateFormatSymbols), that is, private void copyMembers(SymbolsCacheEntry src, DateFormatSymbols dst) { dst.eras = Arrays.copyOf(src.eras, src.eras.length); .... } By doing so, the implementation can avoid premature (and potentially dangerous) DateFormatSymbols subclass instance. Anyway, if Java guarantees that the implementation will never call DateFormatSymbols methods (such as getMonths()) in future and just directly accessing Java's DateFormatSymbols' own fields, then I'm OK with it. (In this case, I would suggest Java team to add some comments in the source code, so future maintainer of the Java code can understand the risk.) Thanks, Yoshito On 6/5/2015 5:53 PM, Naoto Sato wrote: > Umaoka-san, > > I believe the cloning is needed to return the defensive copy, > otherwise an app can mutate the state of the DateFormatSymbols for > other apps. One solution could be to not cache the instance if its > from SPI, but apparently that will affect the performance. I don't see > anything wrong to check if foo is null or not in clone(), since it's a > private property to the provider. > > Naoto > > On 6/5/15 8:31 AM, Yoshito Umaoka wrote: >> Hi folks, >> >> ICU4J implements Java locale service provider interface. I recently >> received a problem report from our customer. When they upgraded Java >> version to 8, the provider implementation stopped working because of NPE >> thrown by our custom DateFormatSymbols subclass. I dug into the problem >> and found that DateFormatSymbols caches its own instance in the >> constructor. Our subclass implementation expects a field is always >> initialized to non-null in the constructor. However, clone() method is >> called for the super class's constructor, the field is not yet >> initialized at the point. >> >> It looks adding 'null' for the field in clone() method would resolve the >> immediate problem, but I'm not comfortable that DateFormatSymbols >> implementation cache a premature instance of my own subclass. If any >> methods overridden by my own subclass is called on a premature instance, >> it might cause another issue. >> >> Anyway, I filed a bug in the Java bug database with the description >> below. For meanwhile, adding simple 'null' check in our code would >> suffice. But I would like to hear Java i18n team's opinion about this >> issue. >> >> Thanks, >> Yoshito >> >> >> --------------------------- >> To implement my own locale service provider, I have a class extending >> java.text.DateFormatSymbols. My custom subclass's constructor implicitly >> invokes the no-args constructor in java.text.DateFormatSymbols. The >> constructor calls a private method - initializeData(Locale). >> >> It looks the implementation was updated in Java 8 and initializeData is >> now trying to cache an instance of DateFormatSymbols at the end and >> calls this.clone(). >> >> In my own subclass implements clone() method, which copies a field >> initialized by a constructor in the class. For example, >> >> =============== >> public class MyDateFormatSymbols extends DateFormatSymbols { >> private final Foo foo; >> >> public MyDateFormatSymbols(Foo foo) { >> if (foo == null) { >> this.foo = new Foo(); >> } else { >> this.foo = foo; >> } >> } >> >> @Override >> public Object clone() { >> MyDateFormatSymbols mdfs = (MyDateFormatSymbols)super.clone(); >> mdfs.foo = this.foo.clone(); >> } >> } >> =============== >> >> When the constructor MyDateFormatSymbols(Foo) is called, it triggers >> no-args constructor of the super class - DateFormatSymbols() first. As I >> explained earlier, Java 8 implementation calls this.clone() in >> DateFormatSymbpls.initializeData(Locale). At that point, the field foo >> in my class is not yet initialized, so this.foo.clone() will throw >> NullPointerException. >> >> My own code expects the field 'foo' is always non-null. I could change >> clone() to check if this.foo is null or not, but I cannot control cached >> 'premature' instance held by Java DateFormatSymbols. At this moment, it >> looks the cache is only used for copying field values maintained by >> DateFormaSymbols itself and never call a method. So, even 'premature' >> instance of my own subclass instance is referenced by DateFormatSymbols, >> it won't cause any problems. However, if the Java's implementation is >> changed to call any DateFormatSymbols method overridden by my own >> subclass, it may not work (because my subclass expects the field foo is >> non-null). >> >> Such code above did not have any problems with earlier Java releases >> (Java 6 / 7). >> >> In my opinion, this.clone() should not be called in DateFormatSymbols >> initialization code. Instead, it should create a private container class >> for these symbols, and cache the object, not DateFormatSymbols itself. From masayoshi.okutsu at oracle.com Mon Jun 8 05:33:49 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 08 Jun 2015 14:33:49 +0900 Subject: DateFormatSymbols triggers this.clone() in the constructor In-Reply-To: <55721A56.90107@oracle.com> References: <5571C0CD.6080801@gmail.com> <55721A56.90107@oracle.com> Message-ID: <5575293D.4060306@oracle.com> I think what Umaoka-san pointed out is valid. Overrideable methods shouldn't be called in a constructor. Masayoshi On 6/6/2015 6:53 AM, Naoto Sato wrote: > Umaoka-san, > > I believe the cloning is needed to return the defensive copy, > otherwise an app can mutate the state of the DateFormatSymbols for > other apps. One solution could be to not cache the instance if its > from SPI, but apparently that will affect the performance. I don't see > anything wrong to check if foo is null or not in clone(), since it's a > private property to the provider. > > Naoto > > On 6/5/15 8:31 AM, Yoshito Umaoka wrote: >> Hi folks, >> >> ICU4J implements Java locale service provider interface. I recently >> received a problem report from our customer. When they upgraded Java >> version to 8, the provider implementation stopped working because of NPE >> thrown by our custom DateFormatSymbols subclass. I dug into the problem >> and found that DateFormatSymbols caches its own instance in the >> constructor. Our subclass implementation expects a field is always >> initialized to non-null in the constructor. However, clone() method is >> called for the super class's constructor, the field is not yet >> initialized at the point. >> >> It looks adding 'null' for the field in clone() method would resolve the >> immediate problem, but I'm not comfortable that DateFormatSymbols >> implementation cache a premature instance of my own subclass. If any >> methods overridden by my own subclass is called on a premature instance, >> it might cause another issue. >> >> Anyway, I filed a bug in the Java bug database with the description >> below. For meanwhile, adding simple 'null' check in our code would >> suffice. But I would like to hear Java i18n team's opinion about this >> issue. >> >> Thanks, >> Yoshito >> >> >> --------------------------- >> To implement my own locale service provider, I have a class extending >> java.text.DateFormatSymbols. My custom subclass's constructor implicitly >> invokes the no-args constructor in java.text.DateFormatSymbols. The >> constructor calls a private method - initializeData(Locale). >> >> It looks the implementation was updated in Java 8 and initializeData is >> now trying to cache an instance of DateFormatSymbols at the end and >> calls this.clone(). >> >> In my own subclass implements clone() method, which copies a field >> initialized by a constructor in the class. For example, >> >> =============== >> public class MyDateFormatSymbols extends DateFormatSymbols { >> private final Foo foo; >> >> public MyDateFormatSymbols(Foo foo) { >> if (foo == null) { >> this.foo = new Foo(); >> } else { >> this.foo = foo; >> } >> } >> >> @Override >> public Object clone() { >> MyDateFormatSymbols mdfs = (MyDateFormatSymbols)super.clone(); >> mdfs.foo = this.foo.clone(); >> } >> } >> =============== >> >> When the constructor MyDateFormatSymbols(Foo) is called, it triggers >> no-args constructor of the super class - DateFormatSymbols() first. As I >> explained earlier, Java 8 implementation calls this.clone() in >> DateFormatSymbpls.initializeData(Locale). At that point, the field foo >> in my class is not yet initialized, so this.foo.clone() will throw >> NullPointerException. >> >> My own code expects the field 'foo' is always non-null. I could change >> clone() to check if this.foo is null or not, but I cannot control cached >> 'premature' instance held by Java DateFormatSymbols. At this moment, it >> looks the cache is only used for copying field values maintained by >> DateFormaSymbols itself and never call a method. So, even 'premature' >> instance of my own subclass instance is referenced by DateFormatSymbols, >> it won't cause any problems. However, if the Java's implementation is >> changed to call any DateFormatSymbols method overridden by my own >> subclass, it may not work (because my subclass expects the field foo is >> non-null). >> >> Such code above did not have any problems with earlier Java releases >> (Java 6 / 7). >> >> In my opinion, this.clone() should not be called in DateFormatSymbols >> initialization code. Instead, it should create a private container class >> for these symbols, and cache the object, not DateFormatSymbols itself. From naoto.sato at oracle.com Mon Jun 8 17:43:35 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 08 Jun 2015 10:43:35 -0700 Subject: DateFormatSymbols triggers this.clone() in the constructor In-Reply-To: <5575293D.4060306@oracle.com> References: <5571C0CD.6080801@gmail.com> <55721A56.90107@oracle.com> <5575293D.4060306@oracle.com> Message-ID: <5575D447.7030600@oracle.com> Okutsu-san, Umaoka-san, OK I got it now. We should cache data fields instead of the object itself. Naoto On 6/7/15 10:33 PM, Masayoshi Okutsu wrote: > I think what Umaoka-san pointed out is valid. Overrideable methods > shouldn't be called in a constructor. > > Masayoshi > > On 6/6/2015 6:53 AM, Naoto Sato wrote: >> Umaoka-san, >> >> I believe the cloning is needed to return the defensive copy, >> otherwise an app can mutate the state of the DateFormatSymbols for >> other apps. One solution could be to not cache the instance if its >> from SPI, but apparently that will affect the performance. I don't see >> anything wrong to check if foo is null or not in clone(), since it's a >> private property to the provider. >> >> Naoto >> >> On 6/5/15 8:31 AM, Yoshito Umaoka wrote: >>> Hi folks, >>> >>> ICU4J implements Java locale service provider interface. I recently >>> received a problem report from our customer. When they upgraded Java >>> version to 8, the provider implementation stopped working because of NPE >>> thrown by our custom DateFormatSymbols subclass. I dug into the problem >>> and found that DateFormatSymbols caches its own instance in the >>> constructor. Our subclass implementation expects a field is always >>> initialized to non-null in the constructor. However, clone() method is >>> called for the super class's constructor, the field is not yet >>> initialized at the point. >>> >>> It looks adding 'null' for the field in clone() method would resolve the >>> immediate problem, but I'm not comfortable that DateFormatSymbols >>> implementation cache a premature instance of my own subclass. If any >>> methods overridden by my own subclass is called on a premature instance, >>> it might cause another issue. >>> >>> Anyway, I filed a bug in the Java bug database with the description >>> below. For meanwhile, adding simple 'null' check in our code would >>> suffice. But I would like to hear Java i18n team's opinion about this >>> issue. >>> >>> Thanks, >>> Yoshito >>> >>> >>> --------------------------- >>> To implement my own locale service provider, I have a class extending >>> java.text.DateFormatSymbols. My custom subclass's constructor implicitly >>> invokes the no-args constructor in java.text.DateFormatSymbols. The >>> constructor calls a private method - initializeData(Locale). >>> >>> It looks the implementation was updated in Java 8 and initializeData is >>> now trying to cache an instance of DateFormatSymbols at the end and >>> calls this.clone(). >>> >>> In my own subclass implements clone() method, which copies a field >>> initialized by a constructor in the class. For example, >>> >>> =============== >>> public class MyDateFormatSymbols extends DateFormatSymbols { >>> private final Foo foo; >>> >>> public MyDateFormatSymbols(Foo foo) { >>> if (foo == null) { >>> this.foo = new Foo(); >>> } else { >>> this.foo = foo; >>> } >>> } >>> >>> @Override >>> public Object clone() { >>> MyDateFormatSymbols mdfs = (MyDateFormatSymbols)super.clone(); >>> mdfs.foo = this.foo.clone(); >>> } >>> } >>> =============== >>> >>> When the constructor MyDateFormatSymbols(Foo) is called, it triggers >>> no-args constructor of the super class - DateFormatSymbols() first. As I >>> explained earlier, Java 8 implementation calls this.clone() in >>> DateFormatSymbpls.initializeData(Locale). At that point, the field foo >>> in my class is not yet initialized, so this.foo.clone() will throw >>> NullPointerException. >>> >>> My own code expects the field 'foo' is always non-null. I could change >>> clone() to check if this.foo is null or not, but I cannot control cached >>> 'premature' instance held by Java DateFormatSymbols. At this moment, it >>> looks the cache is only used for copying field values maintained by >>> DateFormaSymbols itself and never call a method. So, even 'premature' >>> instance of my own subclass instance is referenced by DateFormatSymbols, >>> it won't cause any problems. However, if the Java's implementation is >>> changed to call any DateFormatSymbols method overridden by my own >>> subclass, it may not work (because my subclass expects the field foo is >>> non-null). >>> >>> Such code above did not have any problems with earlier Java releases >>> (Java 6 / 7). >>> >>> In my opinion, this.clone() should not be called in DateFormatSymbols >>> initialization code. Instead, it should create a private container class >>> for these symbols, and cache the object, not DateFormatSymbols itself. > From naoto.sato at oracle.com Mon Jun 8 20:58:31 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 08 Jun 2015 13:58:31 -0700 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) Message-ID: <557601F7.5060209@oracle.com> Hello, Please review the proposed changes for 8008577[1], the implementation of the JEP-252[2]. The proposed changes are located at: http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ Here are the very high level summary of changes: - Now the default locale provider order is CLDR,JRE,SPI. - The CLDR data is upgraded from 21.0.1 to 27.0.0 - According the CLDR upgrade, the converter tool and the runtime are now capable of "alias" and "parentLocales" tags. - Regression tests that are specific to the existing JRE locale data are now run specifically with "JRE,SPI" providers. I would like the build group to review the build changes mainly with the CLDR changes, and i18n group for the rest. Naoto -- [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 From erik.joelsson at oracle.com Tue Jun 9 07:59:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 09 Jun 2015 09:59:41 +0200 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <557601F7.5060209@oracle.com> References: <557601F7.5060209@oracle.com> Message-ID: <55769CED.7000400@oracle.com> Hello Naoto, Build changes look good to me. /Erik On 2015-06-08 22:58, Naoto Sato wrote: > Hello, > > Please review the proposed changes for 8008577[1], the implementation > of the JEP-252[2]. The proposed changes are located at: > > http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ > > Here are the very high level summary of changes: > > - Now the default locale provider order is CLDR,JRE,SPI. > - The CLDR data is upgraded from 21.0.1 to 27.0.0 > - According the CLDR upgrade, the converter tool and the runtime are > now capable of "alias" and "parentLocales" tags. > - Regression tests that are specific to the existing JRE locale data > are now run specifically with "JRE,SPI" providers. > > I would like the build group to review the build changes mainly with > the CLDR changes, and i18n group for the rest. > > Naoto > -- > [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 > [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 From naoto.sato at oracle.com Tue Jun 9 16:56:59 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 09 Jun 2015 09:56:59 -0700 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <55769CED.7000400@oracle.com> References: <557601F7.5060209@oracle.com> <55769CED.7000400@oracle.com> Message-ID: <55771ADB.6040502@oracle.com> Thank you for the quick review, Erik! Naoto On 6/9/15 12:59 AM, Erik Joelsson wrote: > Hello Naoto, > > Build changes look good to me. > > /Erik > > On 2015-06-08 22:58, Naoto Sato wrote: >> Hello, >> >> Please review the proposed changes for 8008577[1], the implementation >> of the JEP-252[2]. The proposed changes are located at: >> >> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >> >> Here are the very high level summary of changes: >> >> - Now the default locale provider order is CLDR,JRE,SPI. >> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >> - According the CLDR upgrade, the converter tool and the runtime are >> now capable of "alias" and "parentLocales" tags. >> - Regression tests that are specific to the existing JRE locale data >> are now run specifically with "JRE,SPI" providers. >> >> I would like the build group to review the build changes mainly with >> the CLDR changes, and i18n group for the rest. >> >> Naoto >> -- >> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 > From masayoshi.okutsu at oracle.com Fri Jun 19 08:53:43 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 19 Jun 2015 17:53:43 +0900 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <557601F7.5060209@oracle.com> References: <557601F7.5060209@oracle.com> Message-ID: <5583D897.30605@oracle.com> Sorry for taking time. Here are my comments. src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: - The year range of the first line of the copyright header should be "2015," for the new ones and "2013, 2015," for the updated ones. - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines because some line spacing is wide in the webrev. (hard to determine that from the webrev.) src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: - applyParentLocales() needs to be thread-safe with parentLocalesMap? src/java.base/share/classes/sun/util/resources/LocaleData.java: - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() implementations should return an optimized candidate list rather than removing unsupported Locales from the list there. test/sun/text/resources/LocaleDataTest.java: + * -cldr option specifies to test CLDR locale data. The default data file name for this + * option is "CLDRLocaleData". - The file name should be "LocaleData.cldr"? test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: - added the bug id, but no changes to the test? Thanks, Masayoshi On 6/9/2015 5:58 AM, Naoto Sato wrote: > Hello, > > Please review the proposed changes for 8008577[1], the implementation > of the JEP-252[2]. The proposed changes are located at: > > http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ > > Here are the very high level summary of changes: > > - Now the default locale provider order is CLDR,JRE,SPI. > - The CLDR data is upgraded from 21.0.1 to 27.0.0 > - According the CLDR upgrade, the converter tool and the runtime are > now capable of "alias" and "parentLocales" tags. > - Regression tests that are specific to the existing JRE locale data > are now run specifically with "JRE,SPI" providers. > > I would like the build group to review the build changes mainly with > the CLDR changes, and i18n group for the rest. > > Naoto > -- > [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 > [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 From naoto.sato at oracle.com Tue Jun 23 21:56:35 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 23 Jun 2015 14:56:35 -0700 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <5583D897.30605@oracle.com> References: <557601F7.5060209@oracle.com> <5583D897.30605@oracle.com> Message-ID: <5589D613.308@oracle.com> Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8008577/webrev.01/ As to the 3rd comment below, I did not modify it because that would simply duplicate the same piece of code in each getCandidateLocales() implementation (from the current location). Naoto On 6/19/15 1:53 AM, Masayoshi Okutsu wrote: > Sorry for taking time. Here are my comments. > > src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: > > - The year range of the first line of the copyright header should be > "2015," for the new ones and "2013, 2015," for the updated ones. > - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines > because some line spacing is wide in the webrev. (hard to determine that > from the webrev.) > > src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: > - applyParentLocales() needs to be thread-safe with parentLocalesMap? > > src/java.base/share/classes/sun/util/resources/LocaleData.java: > - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() > implementations should return an optimized candidate list rather than > removing unsupported Locales from the list there. > > test/sun/text/resources/LocaleDataTest.java: > > + * -cldr option specifies to test CLDR locale data. The default data > file name for this > + * option is "CLDRLocaleData". > > - The file name should be "LocaleData.cldr"? > > test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: > - added the bug id, but no changes to the test? > > Thanks, > Masayoshi > > On 6/9/2015 5:58 AM, Naoto Sato wrote: >> Hello, >> >> Please review the proposed changes for 8008577[1], the implementation >> of the JEP-252[2]. The proposed changes are located at: >> >> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >> >> Here are the very high level summary of changes: >> >> - Now the default locale provider order is CLDR,JRE,SPI. >> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >> - According the CLDR upgrade, the converter tool and the runtime are >> now capable of "alias" and "parentLocales" tags. >> - Regression tests that are specific to the existing JRE locale data >> are now run specifically with "JRE,SPI" providers. >> >> I would like the build group to review the build changes mainly with >> the CLDR changes, and i18n group for the rest. >> >> Naoto >> -- >> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 > From masayoshi.okutsu at oracle.com Wed Jun 24 09:16:54 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 24 Jun 2015 18:16:54 +0900 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <5589D613.308@oracle.com> References: <557601F7.5060209@oracle.com> <5583D897.30605@oracle.com> <5589D613.308@oracle.com> Message-ID: <558A7586.1080603@oracle.com> applyParentLocales() sets parentLocalesMap before populating the map with data. It's possible that other threads look up the map without the (full) data. So, a Map (local variable) should be populated and then parentLocalesMap should be set to the Map. Also, parentLocalesMap needs to be volatile or synchronized should be used when setting it. I don't think it's necessary to use ConcurrentHashMap if the map is not modified after its initialization. Otherwise, the changes look good to me. Masayoshi On 6/24/2015 6:56 AM, Naoto Sato wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8008577/webrev.01/ > > As to the 3rd comment below, I did not modify it because that would > simply duplicate the same piece of code in each getCandidateLocales() > implementation (from the current location). > > Naoto > > On 6/19/15 1:53 AM, Masayoshi Okutsu wrote: >> Sorry for taking time. Here are my comments. >> >> src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: >> >> >> - The year range of the first line of the copyright header should be >> "2015," for the new ones and "2013, 2015," for the updated ones. >> - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines >> because some line spacing is wide in the webrev. (hard to determine that >> from the webrev.) >> >> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: >> >> - applyParentLocales() needs to be thread-safe with parentLocalesMap? >> >> src/java.base/share/classes/sun/util/resources/LocaleData.java: >> - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() >> implementations should return an optimized candidate list rather than >> removing unsupported Locales from the list there. >> >> test/sun/text/resources/LocaleDataTest.java: >> >> + * -cldr option specifies to test CLDR locale data. The default data >> file name for this >> + * option is "CLDRLocaleData". >> >> - The file name should be "LocaleData.cldr"? >> >> test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: >> - added the bug id, but no changes to the test? >> >> Thanks, >> Masayoshi >> >> On 6/9/2015 5:58 AM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the proposed changes for 8008577[1], the implementation >>> of the JEP-252[2]. The proposed changes are located at: >>> >>> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >>> >>> Here are the very high level summary of changes: >>> >>> - Now the default locale provider order is CLDR,JRE,SPI. >>> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >>> - According the CLDR upgrade, the converter tool and the runtime are >>> now capable of "alias" and "parentLocales" tags. >>> - Regression tests that are specific to the existing JRE locale data >>> are now run specifically with "JRE,SPI" providers. >>> >>> I would like the build group to review the build changes mainly with >>> the CLDR changes, and i18n group for the rest. >>> >>> Naoto >>> -- >>> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >>> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 >> From aleksej.efimov at oracle.com Wed Jun 24 11:05:42 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 24 Jun 2015 14:05:42 +0300 Subject: RFR: 8098547: (tz) Support tzdata2015e Message-ID: <558A8F06.5010803@oracle.com> Hello, Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 Testing shows no TZ related failures on all platforms. With Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8098547 From sean.coffey at oracle.com Wed Jun 24 12:58:47 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 24 Jun 2015 13:58:47 +0100 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558A8F06.5010803@oracle.com> References: <558A8F06.5010803@oracle.com> Message-ID: <558AA987.10301@oracle.com> Looks fine. Regards, Sean. On 24/06/15 12:05, Aleksej Efimov wrote: > Hello, > > Please, review the latest tzdata (2015e) [1] integration to JDK9: > http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 > Testing shows no TZ related failures on all platforms. > > With Best Regards, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8098547 From naoto.sato at oracle.com Wed Jun 24 16:15:09 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 24 Jun 2015 09:15:09 -0700 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <558A7586.1080603@oracle.com> References: <557601F7.5060209@oracle.com> <5583D897.30605@oracle.com> <5589D613.308@oracle.com> <558A7586.1080603@oracle.com> Message-ID: <558AD78D.1010407@oracle.com> Thanks. Here is the diff from "webrev.01" to address your comment: http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/b8faab65bb62 Naoto On 6/24/15 2:16 AM, Masayoshi Okutsu wrote: > applyParentLocales() sets parentLocalesMap before populating the map > with data. It's possible that other threads look up the map without the > (full) data. So, a Map (local variable) should be populated and then > parentLocalesMap should be set to the Map. Also, parentLocalesMap needs > to be volatile or synchronized should be used when setting it. I don't > think it's necessary to use ConcurrentHashMap if the map is not modified > after its initialization. > > Otherwise, the changes look good to me. > > Masayoshi > > On 6/24/2015 6:56 AM, Naoto Sato wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~naoto/8008577/webrev.01/ >> >> As to the 3rd comment below, I did not modify it because that would >> simply duplicate the same piece of code in each getCandidateLocales() >> implementation (from the current location). >> >> Naoto >> >> On 6/19/15 1:53 AM, Masayoshi Okutsu wrote: >>> Sorry for taking time. Here are my comments. >>> >>> src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: >>> >>> >>> - The year range of the first line of the copyright header should be >>> "2015," for the new ones and "2013, 2015," for the updated ones. >>> - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines >>> because some line spacing is wide in the webrev. (hard to determine that >>> from the webrev.) >>> >>> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: >>> >>> - applyParentLocales() needs to be thread-safe with parentLocalesMap? >>> >>> src/java.base/share/classes/sun/util/resources/LocaleData.java: >>> - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() >>> implementations should return an optimized candidate list rather than >>> removing unsupported Locales from the list there. >>> >>> test/sun/text/resources/LocaleDataTest.java: >>> >>> + * -cldr option specifies to test CLDR locale data. The default data >>> file name for this >>> + * option is "CLDRLocaleData". >>> >>> - The file name should be "LocaleData.cldr"? >>> >>> test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: >>> - added the bug id, but no changes to the test? >>> >>> Thanks, >>> Masayoshi >>> >>> On 6/9/2015 5:58 AM, Naoto Sato wrote: >>>> Hello, >>>> >>>> Please review the proposed changes for 8008577[1], the implementation >>>> of the JEP-252[2]. The proposed changes are located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >>>> >>>> Here are the very high level summary of changes: >>>> >>>> - Now the default locale provider order is CLDR,JRE,SPI. >>>> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >>>> - According the CLDR upgrade, the converter tool and the runtime are >>>> now capable of "alias" and "parentLocales" tags. >>>> - Regression tests that are specific to the existing JRE locale data >>>> are now run specifically with "JRE,SPI" providers. >>>> >>>> I would like the build group to review the build changes mainly with >>>> the CLDR changes, and i18n group for the rest. >>>> >>>> Naoto >>>> -- >>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >>>> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 >>> > From masayoshi.okutsu at oracle.com Wed Jun 24 23:14:11 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 25 Jun 2015 08:14:11 +0900 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <558AD78D.1010407@oracle.com> References: <557601F7.5060209@oracle.com> <5583D897.30605@oracle.com> <5589D613.308@oracle.com> <558A7586.1080603@oracle.com> <558AD78D.1010407@oracle.com> Message-ID: <558B39C3.5060400@oracle.com> Looks good to me. Masayoshi On 6/25/2015 1:15 AM, Naoto Sato wrote: > Thanks. Here is the diff from "webrev.01" to address your comment: > > http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/b8faab65bb62 > > Naoto > > On 6/24/15 2:16 AM, Masayoshi Okutsu wrote: >> applyParentLocales() sets parentLocalesMap before populating the map >> with data. It's possible that other threads look up the map without the >> (full) data. So, a Map (local variable) should be populated and then >> parentLocalesMap should be set to the Map. Also, parentLocalesMap needs >> to be volatile or synchronized should be used when setting it. I don't >> think it's necessary to use ConcurrentHashMap if the map is not modified >> after its initialization. >> >> Otherwise, the changes look good to me. >> >> Masayoshi >> >> On 6/24/2015 6:56 AM, Naoto Sato wrote: >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~naoto/8008577/webrev.01/ >>> >>> As to the 3rd comment below, I did not modify it because that would >>> simply duplicate the same piece of code in each getCandidateLocales() >>> implementation (from the current location). >>> >>> Naoto >>> >>> On 6/19/15 1:53 AM, Masayoshi Okutsu wrote: >>>> Sorry for taking time. Here are my comments. >>>> >>>> src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: >>>> >>>> >>>> >>>> - The year range of the first line of the copyright header should be >>>> "2015," for the new ones and "2013, 2015," for the updated ones. >>>> - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines >>>> because some line spacing is wide in the webrev. (hard to determine >>>> that >>>> from the webrev.) >>>> >>>> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: >>>> >>>> >>>> - applyParentLocales() needs to be thread-safe with >>>> parentLocalesMap? >>>> >>>> src/java.base/share/classes/sun/util/resources/LocaleData.java: >>>> - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() >>>> implementations should return an optimized candidate list rather than >>>> removing unsupported Locales from the list there. >>>> >>>> test/sun/text/resources/LocaleDataTest.java: >>>> >>>> + * -cldr option specifies to test CLDR locale data. The default data >>>> file name for this >>>> + * option is "CLDRLocaleData". >>>> >>>> - The file name should be "LocaleData.cldr"? >>>> >>>> test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: >>>> - added the bug id, but no changes to the test? >>>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 6/9/2015 5:58 AM, Naoto Sato wrote: >>>>> Hello, >>>>> >>>>> Please review the proposed changes for 8008577[1], the implementation >>>>> of the JEP-252[2]. The proposed changes are located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >>>>> >>>>> Here are the very high level summary of changes: >>>>> >>>>> - Now the default locale provider order is CLDR,JRE,SPI. >>>>> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >>>>> - According the CLDR upgrade, the converter tool and the runtime are >>>>> now capable of "alias" and "parentLocales" tags. >>>>> - Regression tests that are specific to the existing JRE locale data >>>>> are now run specifically with "JRE,SPI" providers. >>>>> >>>>> I would like the build group to review the build changes mainly with >>>>> the CLDR changes, and i18n group for the rest. >>>>> >>>>> Naoto >>>>> -- >>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >>>>> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 >>>> >> From masayoshi.okutsu at oracle.com Thu Jun 25 03:48:02 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 25 Jun 2015 12:48:02 +0900 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558AA987.10301@oracle.com> References: <558A8F06.5010803@oracle.com> <558AA987.10301@oracle.com> Message-ID: <558B79F2.7070300@oracle.com> +1 Masayoshi On 6/24/2015 9:58 PM, Se?n Coffey wrote: > Looks fine. > > Regards, > Sean. > > On 24/06/15 12:05, Aleksej Efimov wrote: >> Hello, >> >> Please, review the latest tzdata (2015e) [1] integration to JDK9: >> http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >> Testing shows no TZ related failures on all platforms. >> >> With Best Regards, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 > From sean.coffey at oracle.com Thu Jun 25 11:02:59 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 25 Jun 2015 12:02:59 +0100 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> Message-ID: <558BDFE3.2030100@oracle.com> That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. Where the 1969 date coming from ? Is there some rollover calculation happening ? Regards, Sean. On 25/06/2015 09:05, Attila Szegedi wrote: > FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? > > [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - > [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' > [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' > > Attila. > >> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: >> >> Hello, >> >> Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >> Testing shows no TZ related failures on all platforms. >> >> With Best Regards, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 From aleksej.efimov at oracle.com Thu Jun 25 11:31:40 2015 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 25 Jun 2015 14:31:40 +0300 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558BDFE3.2030100@oracle.com> References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> <558BDFE3.2030100@oracle.com> Message-ID: <558BE69C.5090805@oracle.com> Attila, Yes - this looks strange to me too. I checked the tzdata releases and there was no changes to Europe/Vienna since the 2014g (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f7de7da2eb58). And as Sean stated the 2015e wasn't pushed to 9-dev repo yet. But, this one [1] was pushed just today and could cause observed failure. To confirm that, can you try to run your nashorn test with -Djava.locale.providers=JRE,SPI (similar to test updates in this bug)? For this tzdata2015e integration - I will run the tzdata tests with 8008577 changes - to confirm that there is no new failures. Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8008577 On 06/25/2015 02:02 PM, Se?n Coffey wrote: > That looks like a strange failure Attila. The timezone in use for that > testcase is Europe/Vienna. > 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. > > Where the 1969 date coming from ? Is there some rollover calculation > happening ? > > Regards, > Sean. > > On 25/06/2015 09:05, Attila Szegedi wrote: >> FWIW, he do have one new test failure in Nashorn now, it seems >> related. Can you confirm it is caused by your changes? >> >> [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - >> [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) >> -954000000 1969-12-20T23:00:00.000Z' >> [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) >> -954000000 1969-12-20T23:00:00.000Z' >> >> Attila. >> >>> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov >>> wrote: >>> >>> Hello, >>> >>> Please, review the latest tzdata (2015e) [1] integration to JDK9: >>> http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >>> Testing shows no TZ related failures on all platforms. >>> >>> With Best Regards, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 > From naoto.sato at oracle.com Thu Jun 25 15:16:24 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 25 Jun 2015 08:16:24 -0700 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> <558BDFE3.2030100@oracle.com> Message-ID: <558C1B48.1010204@oracle.com> Hi Attila, Looks like it's a regression caused by the fix to 8008577, where the default locale data switched to Unicode Consortium's CLDR. Would you please file an issue? Naoto On 6/25/15 5:49 AM, Attila Szegedi wrote: > Yeah, basically instantiating a JavaScript native Date object with (70, 0, -10) and confirming it ends up being 10 days before epoch? > This test failure happened tonight with jdk9, see >, so I presumed it has to be related (no changes to nashorn itself were made). It?s just suddenly the timezone is named ?CEST? instead of ?CET?. > >> On Jun 25, 2015, at 1:02 PM, Se?n Coffey wrote: >> >> That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. >> 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. >> >> Where the 1969 date coming from ? Is there some rollover calculation happening ? >> >> Regards, >> Sean. >> >> On 25/06/2015 09:05, Attila Szegedi wrote: >>> FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? >>> >>> [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - >>> [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' >>> [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' >>> >>> Attila. >>> >>>> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: >>>> >>>> Hello, >>>> >>>> Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >>>> Testing shows no TZ related failures on all platforms. >>>> >>>> With Best Regards, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 >> > From attila.szegedi at oracle.com Thu Jun 25 08:05:42 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 25 Jun 2015 10:05:42 +0200 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558A8F06.5010803@oracle.com> References: <558A8F06.5010803@oracle.com> Message-ID: <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' Attila. > On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: > > Hello, > > Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 > Testing shows no TZ related failures on all platforms. > > With Best Regards, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8098547 From attila.szegedi at oracle.com Thu Jun 25 12:49:13 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 25 Jun 2015 14:49:13 +0200 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558BDFE3.2030100@oracle.com> References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> <558BDFE3.2030100@oracle.com> Message-ID: Yeah, basically instantiating a JavaScript native Date object with (70, 0, -10) and confirming it ends up being 10 days before epoch? This test failure happened tonight with jdk9, see >, so I presumed it has to be related (no changes to nashorn itself were made). It?s just suddenly the timezone is named ?CEST? instead of ?CET?. > On Jun 25, 2015, at 1:02 PM, Se?n Coffey wrote: > > That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. > 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. > > Where the 1969 date coming from ? Is there some rollover calculation happening ? > > Regards, > Sean. > > On 25/06/2015 09:05, Attila Szegedi wrote: >> FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? >> >> [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - >> [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' >> [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' >> >> Attila. >> >>> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: >>> >>> Hello, >>> >>> Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >>> Testing shows no TZ related failures on all platforms. >>> >>> With Best Regards, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 > From attila.szegedi at oracle.com Thu Jun 25 15:26:19 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 25 Jun 2015 17:26:19 +0200 Subject: RFR: 8098547: (tz) Support tzdata2015e In-Reply-To: <558C1B48.1010204@oracle.com> References: <558A8F06.5010803@oracle.com> <4DFDE221-C843-4465-8A3F-7A658AD913C5@oracle.com> <558BDFE3.2030100@oracle.com> <558C1B48.1010204@oracle.com> Message-ID: <381BA948-8852-46AA-A4AC-9C144214BC03@oracle.com> Sure; filed >. (Removed Se?n Coffey from the recipient list as this is not a JDK8 issue.) Attila. > On Jun 25, 2015, at 5:16 PM, Naoto Sato wrote: > > Hi Attila, > > Looks like it's a regression caused by the fix to 8008577, where the default locale data switched to Unicode Consortium's CLDR. Would you please file an issue? > > Naoto > > On 6/25/15 5:49 AM, Attila Szegedi wrote: >> Yeah, basically instantiating a JavaScript native Date object with (70, 0, -10) and confirming it ends up being 10 days before epoch? >> This test failure happened tonight with jdk9, see >, so I presumed it has to be related (no changes to nashorn itself were made). It?s just suddenly the timezone is named ?CEST? instead of ?CET?. >> >>> On Jun 25, 2015, at 1:02 PM, Se?n Coffey wrote: >>> >>> That looks like a strange failure Attila. The timezone in use for that testcase is Europe/Vienna. >>> 2015e tzdata changes haven't been pushed to jdk9-dev forest yet. >>> >>> Where the 1969 date coming from ? Is there some rollover calculation happening ? >>> >>> Regards, >>> Sean. >>> >>> On 25/06/2015 09:05, Attila Szegedi wrote: >>>> FWIW, he do have one new test failure in Nashorn now, it seems related. Can you confirm it is caused by your changes? >>>> >>>> [testng] Test test/script/basic/NASHORN-627.js failed at line 1 - >>>> [testng] expected: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CET) -954000000 1969-12-20T23:00:00.000Z' >>>> [testng] found: 'Sun Dec 21 1969 00:00:00 GMT+0100 (CEST) -954000000 1969-12-20T23:00:00.000Z' >>>> >>>> Attila. >>>> >>>>> On Jun 24, 2015, at 1:05 PM, Aleksej Efimov wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 >>>>> Testing shows no TZ related failures on all platforms. >>>>> >>>>> With Best Regards, >>>>> Aleksej >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8098547 >>> >>