From stuart.marks at oracle.com Mon Nov 4 17:23:58 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 04 Nov 2013 17:23:58 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <527331AE.9080001@orange.fr> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> Message-ID: <527848AE.6010405@oracle.com> On 10/31/13 9:44 PM, Francis ANDRE wrote: > Le 31/10/2013 22:27, Stuart Marks a ?crit : >> It turns out that the debugExec lines emitted by rmid are localized: > If the lines emitted by rmid are localized, then your test "s.indexOf("rmid: > debugExec") != -1" should be also localized or did I miss something? In general we don't localize tests, since they're not delivered to end-users of the product. If we were to localize this test, the localization would be a copy of the localization of rmid, and I don't want to have redundant copies of localization strings spread around the system. >> All locales except the French have no space between "rmid" and the trailing >> colon (":"). It appears that having the space before the colon is proper >> French usage (at least, the other French localizations all appear similar). >> But adding the space to the search string will fix the French locale but will >> break all the other locales. > From my French perspective -- ie, my mother's language -- , I would not add a > space between rmid and the colon... I'm not sure you and I can resolve the correctness of this localization. I'm presuming it's correct, since all the French localizations (at least the ones I found during a brief search) were consistent about this spacing. >> Forcing the test to run in the US locale seems preferable to adding logic to >> deal with different localizations. Since these tests fork JVMs in >> subprocesses, it's probably necessary to do something special to make sure the >> sub-JVMs are in the US locale. This probably involves setting an environment >> variable or a system property. I'm sure others on this list can provide advice. > I think that the best thing to do is removing the space " " before the colon ":" > so that your code will work in any localisation. If it is not possible to remove > this space, then you have to fix the test, taking care the localisation you > mention in the rmid_fr.properties. I don't think we should change the French localizations, unless someone pops up and says "oh yes, these were consistently all done with the wrong spacing." Even if we did, if another locale were to come along that were to change the message so that the test couldn't find the string it's looking for, that would break the test. It's improper for the test to make requirements about how the message string is formatted. Since this test doesn't have anything to do with localization, it seems most sensible for the test to force itself into the US locale, and to force all JVM subprocesses into the US locale as well. > Your test is about the usage message in a localized language, so IMHO, it should > take care of the localization message otherwise I do not understand this code: > TestLibrary.bomb("rmid has incorrect usage message"); Well, this test (CheckUsage) is highly questionable. If you look at the original bug report, https://bugs.openjdk.java.net/browse/jdk-4259564 the bug was that the usage message didn't have a -J option, even though this option was supported in the code. (Also that the usage message was somewhat terse.) In my opinion it was silly for someone to have written a test for a usage message, but it got written anyway. Now, if we were to support running this test under any locale, then the localized usage message (or a portion of it) would have to be copied into the test's resource bundle, or into the test's code itself. Again, this would be bad, because it would replicate localization information in different places in the repository. Worse, since we don't run the test suite in different locales regularly, any divergence between the product's localized messages and the test's localized messages might not be caught for a long time, or the test would pass in some locales but fail in others. The solution here is not to localize the test, or to add logic to the test to look for different messages, but instead to have the test force the JVMs into a known locale so that it doesn't fail when run in an unexpected locale. But for CheckUsage, it's not clear that even doing this is worth the effort. I'd rather just remove this test. There is also another, similar test in test/java/rmi/registry/checkusage. I wouldn't be surprised if it has exactly the same problem. It should be removed too. I've filed https://bugs.openjdk.java.net/browse/JDK-8027810 for removing these tests. Bottom line is that I do not think it makes sense to localize these tests. s'marks >> We test on several platforms as it is; I don't think we'll want to have >> separate test runs for all eleven (or however many) different localizations. >> >> I can see adding code (or test configuration properties or environment >> variables) to ensure that tests are run in the US locale, unless this is >> specifically overridden by the test. It doesn't seem appropriate to add >> locale-specific logic or data structures to the tests, though. > If purpose of the test is to check the localization message, you would have no > other choice to use properties like the previous rmid test. > > Francis >> >> s'marks >> >> >>> diff --git a/test/java/util/Formattable/StockName.java >>> b/test/java/util/Formattable/StockName.java >>> --- a/test/java/util/Formattable/StockName.java >>> +++ b/test/java/util/Formattable/StockName.java >>> @@ -33,83 +33,90 @@ >>> import static java.util.FormattableFlags.*; >>> >>> public class StockName implements Formattable { >>> - private String symbol, companyName, frenchCompanyName; >>> + private String symbol, companyName, frenchCompanyName; >>> >>> - public StockName(String symbol, String companyName, >>> - String frenchCompanyName) >>> - { >>> - this.symbol = symbol; >>> - this.companyName = companyName; >>> - this.frenchCompanyName = frenchCompanyName; >>> - } >>> + public StockName(String symbol, String companyName, String >>> frenchCompanyName) { >>> + this.symbol = symbol; >>> + this.companyName = companyName; >>> + this.frenchCompanyName = frenchCompanyName; >>> + } >>> >>> - public void formatTo(Formatter fmt, int f, int width, int precision){ >>> - StringBuilder sb = new StringBuilder(); >>> + public void formatTo(Formatter fmt, int f, int width, int precision){ >>> + StringBuilder sb = new StringBuilder(); >>> >>> - // decide form of name >>> - String name = companyName; >>> - if (fmt.locale().equals(Locale.FRANCE)) >>> - name = frenchCompanyName; >>> - boolean alternate = (f & ALTERNATE) == ALTERNATE; >>> - boolean usesymbol = alternate || (precision != -1 && precision < 10); >>> - String out = (usesymbol ? symbol : name); >>> + // decide form of name >>> + String name = companyName; >>> + if (fmt.locale().equals(Locale.FRANCE)) >>> + name = frenchCompanyName; >>> + boolean alternate = (f & ALTERNATE) == ALTERNATE; >>> + boolean usesymbol = alternate || (precision != -1 && precision < 10); >>> + String out = (usesymbol ? symbol : name); >>> >>> - // apply precision >>> - if (precision == -1 || out.length() < precision) { >>> - // write it all >>> - sb.append(out); >>> - } else { >>> - sb.append(out.substring(0, precision - 1)).append('*'); >>> - } >>> + // apply precision >>> + if (precision == -1 || out.length() < precision) { >>> + // write it all >>> + sb.append(out); >>> + } else { >>> + sb.append(out.substring(0, precision - 1)).append('*'); >>> + } >>> >>> - // apply width and justification >>> - int len = sb.length(); >>> - if (len < width) >>> - for (int i = 0; i < width - len; i++) >>> - if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY) >>> - sb.append(' '); >>> - else >>> - sb.insert(0, ' '); >>> + // apply width and justification >>> + int len = sb.length(); >>> + if (len < width) >>> + for (int i = 0; i < width - len; i++) >>> + if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY) >>> + sb.append(' '); >>> + else >>> + sb.insert(0, ' '); >>> >>> - fmt.format(sb.toString()); >>> - } >>> + fmt.format(sb.toString()); >>> + } >>> >>> - public String toString() { >>> - return String.format("%s - %s", symbol, companyName); >>> - } >>> + public String toString() { >>> + return String.format("%s - %s", symbol, companyName); >>> + } >>> >>> - public static void main(String [] args) { >>> - StockName sn = new StockName("HUGE", "Huge Fruit, Inc.", >>> - "Fruit Titanesque, Inc."); >>> - CharBuffer cb = CharBuffer.allocate(128); >>> - Formatter fmt = new Formatter(cb); >>> + public static void main(String[] args) { >>> + StockName sn = new StockName("HUGE", "Huge Fruit, Inc.", >>> + "Fruit Titanesque, Inc."); >>> + CharBuffer cb = CharBuffer.allocate(128); >>> + Formatter fmt = new Formatter(cb); >>> >>> - fmt.format("%s", sn); // -> "Huge Fruit, Inc." >>> - test(cb, "Huge Fruit, Inc."); >>> + if (fmt.locale().equals(Locale.FRANCE)) { >>> + fmt.format("%s", sn); // -> "Fruit Titanesque, Inc." >>> + test(cb, "Fruit Titanesque, Inc."); >>> + } else { >>> + fmt.format("%s", sn); // -> "Huge Fruit, Inc." >>> + test(cb, "Huge Fruit, Inc."); >>> + } >>> + fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc." >>> + test(cb, "HUGE - Huge Fruit, Inc."); >>> >>> - fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc." >>> - test(cb, "HUGE - Huge Fruit, Inc."); >>> + fmt.format("%#s", sn); // -> "HUGE" >>> + test(cb, "HUGE"); >>> >>> - fmt.format("%#s", sn); // -> "HUGE" >>> - test(cb, "HUGE"); >>> + fmt.format("%-10.8s", sn); // -> "HUGE " >>> + test(cb, "HUGE "); >>> >>> - fmt.format("%-10.8s", sn); // -> "HUGE " >>> - test(cb, "HUGE "); >>> + if (fmt.locale().equals(Locale.FRANCE)) { >>> + fmt.format("%.12s", sn); // -> "Fruit Titan*" >>> + test(cb, "Fruit Titan*"); >>> + } else { >>> + fmt.format("%.12s", sn); // -> "Huge Fruit,*" >>> + test(cb, "Huge Fruit,*"); >>> + } >>> >>> - fmt.format("%.12s", sn); // -> "Huge Fruit,*" >>> - test(cb, "Huge Fruit,*"); >>> + fmt.format(Locale.FRANCE, "%25s", sn); >>> + // -> " Fruit Titanesque, Inc." >>> + test(cb, " Fruit Titanesque, Inc."); >>> + } >>> >>> - fmt.format(Locale.FRANCE, "%25s", sn); >>> - // -> " Fruit Titanesque, Inc." >>> - test(cb, " Fruit Titanesque, Inc."); >>> - } >>> - >>> - private static void test(CharBuffer cb, String exp) { >>> - cb.limit(cb.position()); >>> - cb.rewind(); >>> - if (!cb.toString().equals(exp)) >>> - throw new RuntimeException("expect: '" + exp + "'; got: '" >>> - + cb.toString() + "'"); >>> - cb.clear(); >>> - } >>> + private static void test(CharBuffer cb, String exp) { >>> + cb.limit(cb.position()); >>> + cb.rewind(); >>> + if (!cb.toString().equals(exp)) >>> + throw new RuntimeException("expect: '" + exp + "'; got: '" >>> + + cb.toString() + "'"); >>> + cb.clear(); >>> + } >>> } >>> diff --git a/test/java/util/ResourceBundle/ResourceBundleTest.java >>> b/test/java/util/ResourceBundle/ResourceBundleTest.java >>> --- a/test/java/util/ResourceBundle/ResourceBundleTest.java >>> +++ b/test/java/util/ResourceBundle/ResourceBundleTest.java >>> @@ -67,6 +67,7 @@ >>> >>> public class ResourceBundleTest extends RBTestFmwk { >>> public static void main(String[] args) throws Exception { >>> + Locale.setDefault(Locale.US); >>> new ResourceBundleTest().run(args); >>> } >>> >>> diff --git >>> a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>> b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>> --- a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>> +++ b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>> @@ -45,6 +45,7 @@ >>> } >>> >>> public static void main(String... args) throws Exception { >>> + Locale.setDefault(Locale.US); >>> >>> Locale defaultLocale = Locale.getDefault(); >>> System.out.println("Default locale is: " + defaultLocale); >>> diff --git a/test/java/util/logging/LocalizedLevelName.java >>> b/test/java/util/logging/LocalizedLevelName.java >>> --- a/test/java/util/logging/LocalizedLevelName.java >>> +++ b/test/java/util/logging/LocalizedLevelName.java >>> @@ -49,6 +49,7 @@ >>> }; >>> >>> public static void main(String args[]) throws Exception { >>> + Locale.setDefault(Locale.US); >>> Locale defaultLocale = Locale.getDefault(); >>> for (int i=0; i>> final String key = (String) namesMap[i]; >>> diff --git a/test/java/util/logging/SimpleFormatterFormat.java >>> b/test/java/util/logging/SimpleFormatterFormat.java >>> --- a/test/java/util/logging/SimpleFormatterFormat.java >>> +++ b/test/java/util/logging/SimpleFormatterFormat.java >>> @@ -30,6 +30,7 @@ >>> */ >>> >>> import java.io.*; >>> +import java.util.Locale; >>> import java.util.logging.*; >>> import java.util.regex.*; >>> >>> @@ -38,7 +39,8 @@ >>> private static final String origFormat = System.getProperty(key); >>> private static final PrintStream err = System.err; >>> public static void main(String[] args) throws Exception { >>> - try { >>> + Locale.setDefault(Locale.US); >>> + try { >>> File dir = new File(System.getProperty("user.dir", ".")); >>> File log = new File(dir, "simpleformat.txt"); >>> java.nio.file.Files.deleteIfExists(log.toPath()); >>> diff --git a/test/sun/util/logging/SourceClassName.java >>> b/test/sun/util/logging/SourceClassName.java >>> --- a/test/sun/util/logging/SourceClassName.java >>> +++ b/test/sun/util/logging/SourceClassName.java >>> @@ -31,12 +31,14 @@ >>> * @run main/othervm SourceClassName >>> */ >>> >>> +import java.util.Locale; >>> import java.util.logging.*; >>> import java.io.*; >>> import sun.util.logging.PlatformLogger; >>> >>> public class SourceClassName { >>> public static void main(String[] args) throws Exception { >>> + Locale.setDefault(Locale.US); >>> File dir = new File(System.getProperty("user.dir", ".")); >>> File log = new File(dir, "testlog.txt"); >>> PrintStream logps = new PrintStream(log); >>> >> > From francis.andre.kampbell at orange.fr Mon Nov 4 19:39:30 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Tue, 05 Nov 2013 04:39:30 +0100 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <527848AE.6010405@oracle.com> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> Message-ID: <52786872.7010806@orange.fr> Stuart Le 05/11/2013 02:23, Stuart Marks a ?crit : > On 10/31/13 9:44 PM, Francis ANDRE wrote: >> Le 31/10/2013 22:27, Stuart Marks a ?crit : >>> It turns out that the debugExec lines emitted by rmid are localized: >> If the lines emitted by rmid are localized, then your test "s.indexOf("rmid: >> debugExec") != -1" should be also localized or did I miss something? > > In general we don't localize tests, since they're not delivered to end-users > of the product. If we were to localize this test, the localization would be a > copy of the localization of rmid, and I don't want to have redundant copies of > localization strings spread around the system. Stuart. the jtreg jdk test should pass OK on all platforms where OpenJDK could be build. So tests that test the localization feature of the jdk should be localized, otherwise they will failed on non US platform. > >>> All locales except the French have no space between "rmid" and the trailing >>> colon (":"). It appears that having the space before the colon is proper >>> French usage (at least, the other French localizations all appear similar). >>> But adding the space to the search string will fix the French locale but will >>> break all the other locales. >> From my French perspective -- ie, my mother's language -- , I would not add a >> space between rmid and the colon... > > I'm not sure you and I can resolve the correctness of this localization. I'm > presuming it's correct, since all the French localizations (at least the ones > I found during a brief search) were consistent about this spacing. Yes, from a strictly speaking French syntax, you are right, there is a space before and after the colon, but it is not really offending if there space before the colon was removed. > >>> Forcing the test to run in the US locale seems preferable to adding logic to >>> deal with different localizations. Since these tests fork JVMs in >>> subprocesses, it's probably necessary to do something special to make sure the >>> sub-JVMs are in the US locale. This probably involves setting an environment >>> variable or a system property. I'm sure others on this list can provide advice. >> I think that the best thing to do is removing the space " " before the colon ":" >> so that your code will work in any localisation. If it is not possible to remove >> this space, then you have to fix the test, taking care the localisation you >> mention in the rmid_fr.properties. > > I don't think we should change the French localizations, unless someone pops > up and says "oh yes, these were consistently all done with the wrong spacing." > Even if we did, if another locale were to come along that were to change the > message so that the test couldn't find the string it's looking for, that would > break the test. It's improper for the test to make requirements about how the > message string is formatted. > > Since this test doesn't have anything to do with localization, it seems most > sensible for the test to force itself into the US locale, and to force all JVM > subprocesses into the US locale as well. > >> Your test is about the usage message in a localized language, so IMHO, it should >> take care of the localization message otherwise I do not understand this code: >> TestLibrary.bomb("rmid has incorrect usage message"); > > Well, this test (CheckUsage) is highly questionable. If you look at the > original bug report, > > https://bugs.openjdk.java.net/browse/jdk-4259564 > > the bug was that the usage message didn't have a -J option, even though this > option was supported in the code. (Also that the usage message was somewhat > terse.) In my opinion it was silly for someone to have written a test for a > usage message, but it got written anyway. > > Now, if we were to support running this test under any locale, then the > localized usage message (or a portion of it) would have to be copied into the > test's resource bundle, or into the test's code itself. Again, this would be > bad, because it would replicate localization information in different places > in the repository. > > Worse, since we don't run the test suite in different locales regularly, any > divergence between the product's localized messages and the test's localized > messages might not be caught for a long time, or the test would pass in some > locales but fail in others. > > The solution here is not to localize the test, or to add logic to the test to > look for different messages, but instead to have the test force the JVMs into > a known locale so that it doesn't fail when run in an unexpected locale. > > But for CheckUsage, it's not clear that even doing this is worth the effort. > I'd rather just remove this test. > > There is also another, similar test in test/java/rmi/registry/checkusage. I > wouldn't be surprised if it has exactly the same problem. It should be removed > too. I've filed > > https://bugs.openjdk.java.net/browse/JDK-8027810 > > for removing these tests. > > Bottom line is that I do not think it makes sense to localize these tests. Stuart, as I already mention before, what is important is that the jdk tests pass OK whatever country there are run. So those specific tests that fails even if the localization is preset to Locale.US must be corrected to pass in non US country or removed. > > s'marks > > >>> We test on several platforms as it is; I don't think we'll want to have >>> separate test runs for all eleven (or however many) different localizations. >>> >>> I can see adding code (or test configuration properties or environment >>> variables) to ensure that tests are run in the US locale, unless this is >>> specifically overridden by the test. It doesn't seem appropriate to add >>> locale-specific logic or data structures to the tests, though. >> If purpose of the test is to check the localization message, you would have no >> other choice to use properties like the previous rmid test. >> >> Francis >>> >>> s'marks >>> >>> >>>> diff --git a/test/java/util/Formattable/StockName.java >>>> b/test/java/util/Formattable/StockName.java >>>> --- a/test/java/util/Formattable/StockName.java >>>> +++ b/test/java/util/Formattable/StockName.java >>>> @@ -33,83 +33,90 @@ >>>> import static java.util.FormattableFlags.*; >>>> >>>> public class StockName implements Formattable { >>>> - private String symbol, companyName, frenchCompanyName; >>>> + private String symbol, companyName, frenchCompanyName; >>>> >>>> - public StockName(String symbol, String companyName, >>>> - String frenchCompanyName) >>>> - { >>>> - this.symbol = symbol; >>>> - this.companyName = companyName; >>>> - this.frenchCompanyName = frenchCompanyName; >>>> - } >>>> + public StockName(String symbol, String companyName, String >>>> frenchCompanyName) { >>>> + this.symbol = symbol; >>>> + this.companyName = companyName; >>>> + this.frenchCompanyName = frenchCompanyName; >>>> + } >>>> >>>> - public void formatTo(Formatter fmt, int f, int width, int precision){ >>>> - StringBuilder sb = new StringBuilder(); >>>> + public void formatTo(Formatter fmt, int f, int width, int precision){ >>>> + StringBuilder sb = new StringBuilder(); >>>> >>>> - // decide form of name >>>> - String name = companyName; >>>> - if (fmt.locale().equals(Locale.FRANCE)) >>>> - name = frenchCompanyName; >>>> - boolean alternate = (f & ALTERNATE) == ALTERNATE; >>>> - boolean usesymbol = alternate || (precision != -1 && precision < 10); >>>> - String out = (usesymbol ? symbol : name); >>>> + // decide form of name >>>> + String name = companyName; >>>> + if (fmt.locale().equals(Locale.FRANCE)) >>>> + name = frenchCompanyName; >>>> + boolean alternate = (f & ALTERNATE) == ALTERNATE; >>>> + boolean usesymbol = alternate || (precision != -1 && precision < 10); >>>> + String out = (usesymbol ? symbol : name); >>>> >>>> - // apply precision >>>> - if (precision == -1 || out.length() < precision) { >>>> - // write it all >>>> - sb.append(out); >>>> - } else { >>>> - sb.append(out.substring(0, precision - 1)).append('*'); >>>> - } >>>> + // apply precision >>>> + if (precision == -1 || out.length() < precision) { >>>> + // write it all >>>> + sb.append(out); >>>> + } else { >>>> + sb.append(out.substring(0, precision - 1)).append('*'); >>>> + } >>>> >>>> - // apply width and justification >>>> - int len = sb.length(); >>>> - if (len < width) >>>> - for (int i = 0; i < width - len; i++) >>>> - if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY) >>>> - sb.append(' '); >>>> - else >>>> - sb.insert(0, ' '); >>>> + // apply width and justification >>>> + int len = sb.length(); >>>> + if (len < width) >>>> + for (int i = 0; i < width - len; i++) >>>> + if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY) >>>> + sb.append(' '); >>>> + else >>>> + sb.insert(0, ' '); >>>> >>>> - fmt.format(sb.toString()); >>>> - } >>>> + fmt.format(sb.toString()); >>>> + } >>>> >>>> - public String toString() { >>>> - return String.format("%s - %s", symbol, companyName); >>>> - } >>>> + public String toString() { >>>> + return String.format("%s - %s", symbol, companyName); >>>> + } >>>> >>>> - public static void main(String [] args) { >>>> - StockName sn = new StockName("HUGE", "Huge Fruit, Inc.", >>>> - "Fruit Titanesque, Inc."); >>>> - CharBuffer cb = CharBuffer.allocate(128); >>>> - Formatter fmt = new Formatter(cb); >>>> + public static void main(String[] args) { >>>> + StockName sn = new StockName("HUGE", "Huge Fruit, Inc.", >>>> + "Fruit Titanesque, Inc."); >>>> + CharBuffer cb = CharBuffer.allocate(128); >>>> + Formatter fmt = new Formatter(cb); >>>> >>>> - fmt.format("%s", sn); // -> "Huge Fruit, Inc." >>>> - test(cb, "Huge Fruit, Inc."); >>>> + if (fmt.locale().equals(Locale.FRANCE)) { >>>> + fmt.format("%s", sn); // -> "Fruit Titanesque, Inc." >>>> + test(cb, "Fruit Titanesque, Inc."); >>>> + } else { >>>> + fmt.format("%s", sn); // -> "Huge Fruit, Inc." >>>> + test(cb, "Huge Fruit, Inc."); >>>> + } >>>> + fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc." >>>> + test(cb, "HUGE - Huge Fruit, Inc."); >>>> >>>> - fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc." >>>> - test(cb, "HUGE - Huge Fruit, Inc."); >>>> + fmt.format("%#s", sn); // -> "HUGE" >>>> + test(cb, "HUGE"); >>>> >>>> - fmt.format("%#s", sn); // -> "HUGE" >>>> - test(cb, "HUGE"); >>>> + fmt.format("%-10.8s", sn); // -> "HUGE " >>>> + test(cb, "HUGE "); >>>> >>>> - fmt.format("%-10.8s", sn); // -> "HUGE " >>>> - test(cb, "HUGE "); >>>> + if (fmt.locale().equals(Locale.FRANCE)) { >>>> + fmt.format("%.12s", sn); // -> "Fruit Titan*" >>>> + test(cb, "Fruit Titan*"); >>>> + } else { >>>> + fmt.format("%.12s", sn); // -> "Huge Fruit,*" >>>> + test(cb, "Huge Fruit,*"); >>>> + } >>>> >>>> - fmt.format("%.12s", sn); // -> "Huge Fruit,*" >>>> - test(cb, "Huge Fruit,*"); >>>> + fmt.format(Locale.FRANCE, "%25s", sn); >>>> + // -> " Fruit Titanesque, Inc." >>>> + test(cb, " Fruit Titanesque, Inc."); >>>> + } >>>> >>>> - fmt.format(Locale.FRANCE, "%25s", sn); >>>> - // -> " Fruit Titanesque, Inc." >>>> - test(cb, " Fruit Titanesque, Inc."); >>>> - } >>>> - >>>> - private static void test(CharBuffer cb, String exp) { >>>> - cb.limit(cb.position()); >>>> - cb.rewind(); >>>> - if (!cb.toString().equals(exp)) >>>> - throw new RuntimeException("expect: '" + exp + "'; got: '" >>>> - + cb.toString() + "'"); >>>> - cb.clear(); >>>> - } >>>> + private static void test(CharBuffer cb, String exp) { >>>> + cb.limit(cb.position()); >>>> + cb.rewind(); >>>> + if (!cb.toString().equals(exp)) >>>> + throw new RuntimeException("expect: '" + exp + "'; got: '" >>>> + + cb.toString() + "'"); >>>> + cb.clear(); >>>> + } >>>> } >>>> diff --git a/test/java/util/ResourceBundle/ResourceBundleTest.java >>>> b/test/java/util/ResourceBundle/ResourceBundleTest.java >>>> --- a/test/java/util/ResourceBundle/ResourceBundleTest.java >>>> +++ b/test/java/util/ResourceBundle/ResourceBundleTest.java >>>> @@ -67,6 +67,7 @@ >>>> >>>> public class ResourceBundleTest extends RBTestFmwk { >>>> public static void main(String[] args) throws Exception { >>>> + Locale.setDefault(Locale.US); >>>> new ResourceBundleTest().run(args); >>>> } >>>> >>>> diff --git >>>> a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>>> b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>>> --- >>>> a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>>> +++ >>>> b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>>> @@ -45,6 +45,7 @@ >>>> } >>>> >>>> public static void main(String... args) throws Exception { >>>> + Locale.setDefault(Locale.US); >>>> >>>> Locale defaultLocale = Locale.getDefault(); >>>> System.out.println("Default locale is: " + defaultLocale); >>>> diff --git a/test/java/util/logging/LocalizedLevelName.java >>>> b/test/java/util/logging/LocalizedLevelName.java >>>> --- a/test/java/util/logging/LocalizedLevelName.java >>>> +++ b/test/java/util/logging/LocalizedLevelName.java >>>> @@ -49,6 +49,7 @@ >>>> }; >>>> >>>> public static void main(String args[]) throws Exception { >>>> + Locale.setDefault(Locale.US); >>>> Locale defaultLocale = Locale.getDefault(); >>>> for (int i=0; i>>> final String key = (String) namesMap[i]; >>>> diff --git a/test/java/util/logging/SimpleFormatterFormat.java >>>> b/test/java/util/logging/SimpleFormatterFormat.java >>>> --- a/test/java/util/logging/SimpleFormatterFormat.java >>>> +++ b/test/java/util/logging/SimpleFormatterFormat.java >>>> @@ -30,6 +30,7 @@ >>>> */ >>>> >>>> import java.io.*; >>>> +import java.util.Locale; >>>> import java.util.logging.*; >>>> import java.util.regex.*; >>>> >>>> @@ -38,7 +39,8 @@ >>>> private static final String origFormat = System.getProperty(key); >>>> private static final PrintStream err = System.err; >>>> public static void main(String[] args) throws Exception { >>>> - try { >>>> + Locale.setDefault(Locale.US); >>>> + try { >>>> File dir = new File(System.getProperty("user.dir", ".")); >>>> File log = new File(dir, "simpleformat.txt"); >>>> java.nio.file.Files.deleteIfExists(log.toPath()); >>>> diff --git a/test/sun/util/logging/SourceClassName.java >>>> b/test/sun/util/logging/SourceClassName.java >>>> --- a/test/sun/util/logging/SourceClassName.java >>>> +++ b/test/sun/util/logging/SourceClassName.java >>>> @@ -31,12 +31,14 @@ >>>> * @run main/othervm SourceClassName >>>> */ >>>> >>>> +import java.util.Locale; >>>> import java.util.logging.*; >>>> import java.io.*; >>>> import sun.util.logging.PlatformLogger; >>>> >>>> public class SourceClassName { >>>> public static void main(String[] args) throws Exception { >>>> + Locale.setDefault(Locale.US); >>>> File dir = new File(System.getProperty("user.dir", ".")); >>>> File log = new File(dir, "testlog.txt"); >>>> PrintStream logps = new PrintStream(log); >>>> >>> >> > From michael.fang at oracle.com Mon Nov 4 21:56:39 2013 From: michael.fang at oracle.com (Michael Fang) Date: Mon, 04 Nov 2013 21:56:39 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <527331AE.9080001@orange.fr> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> Message-ID: <52788897.1000900@oracle.com> Hi Francis, I am the one coordinating the translation of resource files. I have asked the translators about the extra space in the past for another file and they replied: Please note that this is not an error but a French standard. In French, we use a space before a colon. Typically, we do not add jtreg tests to test the translation because the translation is not "code". Translation is tested with separate in-house test suites. thanks, -michael On 13?10?31? 09:44 ??, Francis ANDRE wrote: > Hi Stuart > > Please see my comments through the mail > Le 31/10/2013 22:27, Stuart Marks a ?crit : >> Hi Francis, >> >> Alan Bateman directed me to this patch since it includes changes to >> the RMI tests, which I maintain. I have a few comments on the changes >> to these tests. >> >>> From: Francis ANDRE >>> >>> Following are a list of patch for making the jdk jtreg test suite >>> happy with a >>> WXP/Cygwin/VS2010 Franch platform. For most of them, the fix >>> consists in adding >>> Locale.setDefault(Locale.US); as the first statement in main. >>> >>> diff --git >>> a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java >>> b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java >>> --- a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java >>> +++ b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java >>> @@ -238,7 +238,7 @@ >>> >>> public synchronized void notifyLine(String s) >>> { >>> - if (s != null && s.indexOf("rmid: debugExec") != -1) >>> + if (s != null && s.indexOf("rmid : debugExec") != -1) >>> found = s; >>> } >>> >> >> This is somewhat odd. This section of the test is capturing the >> output of rmid and is scanning it for a particular string. Why would >> adding a space be necessary? It turns out that the debugExec lines >> emitted by rmid are localized: > If the lines emitted by rmid are localized, then your test > "s.indexOf("rmid: debugExec") != -1" should be also localized or did I > miss something? >> >> >> $ cd jdk/src/share/classes/sun/rmi/server/resources >> $ grep rmid.exec.command *_*.properties >> rmid_de.properties:rmid.exec.command=rmid: debugExec: "{0}" wird >> ausgef\u00FChrt >> rmid_es.properties:rmid.exec.command=rmid: debugExec: en >> ejecuci\u00F3n "{0}" >> rmid_fr.properties:rmid.exec.command=rmid : debugExec : >> ex\u00E9cution de "{0}" >> rmid_it.properties:rmid.exec.command=rmid: debugExec: esecuzione di >> "{0}" in corso >> rmid_ja.properties:rmid.exec.command=rmid: debugExec: >> "{0}"\u3092\u5B9F\u884C\u4E2D >> rmid_ko.properties:rmid.exec.command=rmid: debugExec: "{0}" >> \uC2E4\uD589 \uC911 >> rmid_pt_BR.properties:rmid.exec.command=rmid: debugExec: executando >> "{0}" >> rmid_sv.properties:rmid.exec.command=rmid: debugExec: k\u00F6r "{0}" >> rmid_zh_CN.properties:rmid.exec.command=rmid: debugExec: >> \u6B63\u5728\u8FD0\u884C "{0}" >> rmid_zh_TW.properties:rmid.exec.command=rmid: debugExec: \u57F7\u884C >> "{0}" >> $ grep -B 0 -A 1 rmid.exec.command rmid.properties >> rmid.exec.command=\ >> rmid: debugExec: running "{0}" >> >> >> All locales except the French have no space between "rmid" and the >> trailing colon (":"). It appears that having the space before the >> colon is proper French usage (at least, the other French >> localizations all appear similar). But adding the space to the search >> string will fix the French locale but will break all the other locales. > From my French perspective -- ie, my mother's language -- , I would > not add a space between rmid and the colon... >> >> Forcing the test to run in the US locale seems preferable to adding >> logic to deal with different localizations. Since these tests fork >> JVMs in subprocesses, it's probably necessary to do something special >> to make sure the sub-JVMs are in the US locale. This probably >> involves setting an environment variable or a system property. I'm >> sure others on this list can provide advice. > I think that the best thing to do is removing the space " " before the > colon ":" so that your code will work in any localisation. If it is > not possible to remove this space, then you have to fix the test, > taking care the localisation you mention in the rmid_fr.properties. > Here the report of the test > > RMID: starting rmid on port #3882... > ACTIVATION_LIBRARY: Activation System available after 0 milliseconds > RMID: finished starting rmid. > rmid : debugExec : ex?cution de > "Z:\JDK\jdk8\build\WINDOW~1\images\J2SDK-~1\jre\bin\java > -Djava.security.manager=default > -Djava.security.policy=Z:\JDK\jdk8\jdk\test\java\rmi\activation\CommandEnvironment\group.security.policy > -Dtest.src=Z:\JDK\jdk8\jdk\test\java\rmi\activation\CommandEnvironment > -Dtest.classes=Z:\JDK\jdk8\build\windows-x86-normal-server-release\testoutput\jdk_rmi\JTwork\classes\0\java\rmi\activation\CommandEnvironment > -Djava.rmi.server.useCodebaseOnly=false > sun.rmi.server.ActivationGroupInit" > Tue Oct 29 08:15:08 CET 2013:ExecGroup-0:out:Doctor constructed and > exported > Tue Oct 29 08:15:08 CET 2013:ExecGroup-0:out:Doctor will see you now > TEST FAILED: rmid subprocess produced no recognizable debugExec line > >> >> >>> diff --git a/test/java/rmi/activation/checkusage/CheckUsage.java >>> b/test/java/rmi/activation/checkusage/CheckUsage.java >>> --- a/test/java/rmi/activation/checkusage/CheckUsage.java >>> +++ b/test/java/rmi/activation/checkusage/CheckUsage.java >>> @@ -31,12 +31,20 @@ >>> */ >>> >>> import java.io.ByteArrayOutputStream; >>> +import java.util.HashMap; >>> +import java.util.Locale; >>> +import java.util.Map; >>> >>> /** >>> * Make sure that rmid prints out a correct usage statement when run >>> with an >>> * incorrect command line. >>> */ >>> public class CheckUsage { >>> + private static final Map maps = new >>> HashMap(); >>> + static { >>> + maps.put(Locale.ENGLISH.getDisplayLanguage(), "runtime flag"); >>> + maps.put(Locale.FRENCH.getDisplayLanguage(), "indicateur >>> d'ex?cution"); >>> + } >>> public static void main(String[] args) { >>> try { >>> ByteArrayOutputStream berr = new ByteArrayOutputStream(); >>> @@ -54,8 +62,9 @@ >>> String usage = new String(berr.toByteArray()); >>> >>> System.err.println("rmid usage: " + usage); >>> - >>> - if (usage.indexOf("-J") < 0) { >>> + >>> + String jflag = "-J<" + >>> maps.get(Locale.getDefault().getDisplayLanguage()) + ">"; >>> + if (usage.indexOf(jflag) < 0) { >>> TestLibrary.bomb("rmid has incorrect usage message"); >>> } else { >>> System.err.println("test passed"); >> >> >> This change looks like the start of a map that includes localized >> usage messages from various locales. If we were to expand this to >> other locales, eventually we'd end up duplicating all the localized >> usage messages into the test code. That seems pretty fragile. >> >> As above, this is capturing the output of a subprocess, so it would >> seem better if the subprocess were forced into the US locale. >> >> (In fact, this is kind of a stupid test anyway; all it does is make >> sure that a usage message gets emitted if an erroneous command-line >> option is provided. I've been thinking of removing it. It's certainly >> not worth adding extra logic to handle multiple locales.) >> >> -- >> >> Do we even support running the test suite in different locales? > Your test is about the usage message in a localized language, so IMHO, > it should take care of the localization message otherwise I do not > understand this code: TestLibrary.bomb("rmid has incorrect usage > message"); >> We test on several platforms as it is; I don't think we'll want to >> have separate test runs for all eleven (or however many) different >> localizations. >> >> I can see adding code (or test configuration properties or >> environment variables) to ensure that tests are run in the US locale, >> unless this is specifically overridden by the test. It doesn't seem >> appropriate to add locale-specific logic or data structures to the >> tests, though. > If purpose of the test is to check the localization message, you would > have no other choice to use properties like the previous rmid test. > > Francis >> >> s'marks >> >> >>> diff --git a/test/java/util/Formattable/StockName.java >>> b/test/java/util/Formattable/StockName.java >>> --- a/test/java/util/Formattable/StockName.java >>> +++ b/test/java/util/Formattable/StockName.java >>> @@ -33,83 +33,90 @@ >>> import static java.util.FormattableFlags.*; >>> >>> public class StockName implements Formattable { >>> - private String symbol, companyName, frenchCompanyName; >>> + private String symbol, companyName, frenchCompanyName; >>> >>> - public StockName(String symbol, String companyName, >>> - String frenchCompanyName) >>> - { >>> - this.symbol = symbol; >>> - this.companyName = companyName; >>> - this.frenchCompanyName = frenchCompanyName; >>> - } >>> + public StockName(String symbol, String companyName, String >>> frenchCompanyName) { >>> + this.symbol = symbol; >>> + this.companyName = companyName; >>> + this.frenchCompanyName = frenchCompanyName; >>> + } >>> >>> - public void formatTo(Formatter fmt, int f, int width, int precision){ >>> - StringBuilder sb = new StringBuilder(); >>> + public void formatTo(Formatter fmt, int f, int width, int precision){ >>> + StringBuilder sb = new StringBuilder(); >>> >>> - // decide form of name >>> - String name = companyName; >>> - if (fmt.locale().equals(Locale.FRANCE)) >>> - name = frenchCompanyName; >>> - boolean alternate = (f & ALTERNATE) == ALTERNATE; >>> - boolean usesymbol = alternate || (precision != -1 && precision < 10); >>> - String out = (usesymbol ? symbol : name); >>> + // decide form of name >>> + String name = companyName; >>> + if (fmt.locale().equals(Locale.FRANCE)) >>> + name = frenchCompanyName; >>> + boolean alternate = (f & ALTERNATE) == ALTERNATE; >>> + boolean usesymbol = alternate || (precision != -1 && precision < 10); >>> + String out = (usesymbol ? symbol : name); >>> >>> - // apply precision >>> - if (precision == -1 || out.length() < precision) { >>> - // write it all >>> - sb.append(out); >>> - } else { >>> - sb.append(out.substring(0, precision - 1)).append('*'); >>> - } >>> + // apply precision >>> + if (precision == -1 || out.length() < precision) { >>> + // write it all >>> + sb.append(out); >>> + } else { >>> + sb.append(out.substring(0, precision - 1)).append('*'); >>> + } >>> >>> - // apply width and justification >>> - int len = sb.length(); >>> - if (len < width) >>> - for (int i = 0; i < width - len; i++) >>> - if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY) >>> - sb.append(' '); >>> - else >>> - sb.insert(0, ' '); >>> + // apply width and justification >>> + int len = sb.length(); >>> + if (len < width) >>> + for (int i = 0; i < width - len; i++) >>> + if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY) >>> + sb.append(' '); >>> + else >>> + sb.insert(0, ' '); >>> >>> - fmt.format(sb.toString()); >>> - } >>> + fmt.format(sb.toString()); >>> + } >>> >>> - public String toString() { >>> - return String.format("%s - %s", symbol, companyName); >>> - } >>> + public String toString() { >>> + return String.format("%s - %s", symbol, companyName); >>> + } >>> >>> - public static void main(String [] args) { >>> - StockName sn = new StockName("HUGE", "Huge Fruit, Inc.", >>> - "Fruit Titanesque, Inc."); >>> - CharBuffer cb = CharBuffer.allocate(128); >>> - Formatter fmt = new Formatter(cb); >>> + public static void main(String[] args) { >>> + StockName sn = new StockName("HUGE", "Huge Fruit, Inc.", >>> + "Fruit Titanesque, Inc."); >>> + CharBuffer cb = CharBuffer.allocate(128); >>> + Formatter fmt = new Formatter(cb); >>> >>> - fmt.format("%s", sn); // -> "Huge Fruit, Inc." >>> - test(cb, "Huge Fruit, Inc."); >>> + if (fmt.locale().equals(Locale.FRANCE)) { >>> + fmt.format("%s", sn); // -> "Fruit Titanesque, Inc." >>> + test(cb, "Fruit Titanesque, Inc."); >>> + } else { >>> + fmt.format("%s", sn); // -> "Huge Fruit, Inc." >>> + test(cb, "Huge Fruit, Inc."); >>> + } >>> + fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc." >>> + test(cb, "HUGE - Huge Fruit, Inc."); >>> >>> - fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc." >>> - test(cb, "HUGE - Huge Fruit, Inc."); >>> + fmt.format("%#s", sn); // -> "HUGE" >>> + test(cb, "HUGE"); >>> >>> - fmt.format("%#s", sn); // -> "HUGE" >>> - test(cb, "HUGE"); >>> + fmt.format("%-10.8s", sn); // -> "HUGE " >>> + test(cb, "HUGE "); >>> >>> - fmt.format("%-10.8s", sn); // -> "HUGE " >>> - test(cb, "HUGE "); >>> + if (fmt.locale().equals(Locale.FRANCE)) { >>> + fmt.format("%.12s", sn); // -> "Fruit Titan*" >>> + test(cb, "Fruit Titan*"); >>> + } else { >>> + fmt.format("%.12s", sn); // -> "Huge Fruit,*" >>> + test(cb, "Huge Fruit,*"); >>> + } >>> >>> - fmt.format("%.12s", sn); // -> "Huge Fruit,*" >>> - test(cb, "Huge Fruit,*"); >>> + fmt.format(Locale.FRANCE, "%25s", sn); >>> + // -> " Fruit Titanesque, Inc." >>> + test(cb, " Fruit Titanesque, Inc."); >>> + } >>> >>> - fmt.format(Locale.FRANCE, "%25s", sn); >>> - // -> " Fruit Titanesque, Inc." >>> - test(cb, " Fruit Titanesque, Inc."); >>> - } >>> - >>> - private static void test(CharBuffer cb, String exp) { >>> - cb.limit(cb.position()); >>> - cb.rewind(); >>> - if (!cb.toString().equals(exp)) >>> - throw new RuntimeException("expect: '" + exp + "'; got: '" >>> - + cb.toString() + "'"); >>> - cb.clear(); >>> - } >>> + private static void test(CharBuffer cb, String exp) { >>> + cb.limit(cb.position()); >>> + cb.rewind(); >>> + if (!cb.toString().equals(exp)) >>> + throw new RuntimeException("expect: '" + exp + "'; got: '" >>> + + cb.toString() + "'"); >>> + cb.clear(); >>> + } >>> } >>> diff --git a/test/java/util/ResourceBundle/ResourceBundleTest.java >>> b/test/java/util/ResourceBundle/ResourceBundleTest.java >>> --- a/test/java/util/ResourceBundle/ResourceBundleTest.java >>> +++ b/test/java/util/ResourceBundle/ResourceBundleTest.java >>> @@ -67,6 +67,7 @@ >>> >>> public class ResourceBundleTest extends RBTestFmwk { >>> public static void main(String[] args) throws Exception { >>> + Locale.setDefault(Locale.US); >>> new ResourceBundleTest().run(args); >>> } >>> >>> diff --git >>> a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>> >>> b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>> >>> --- >>> a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>> +++ >>> b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>> @@ -45,6 +45,7 @@ >>> } >>> >>> public static void main(String... args) throws Exception { >>> + Locale.setDefault(Locale.US); >>> >>> Locale defaultLocale = Locale.getDefault(); >>> System.out.println("Default locale is: " + defaultLocale); >>> diff --git a/test/java/util/logging/LocalizedLevelName.java >>> b/test/java/util/logging/LocalizedLevelName.java >>> --- a/test/java/util/logging/LocalizedLevelName.java >>> +++ b/test/java/util/logging/LocalizedLevelName.java >>> @@ -49,6 +49,7 @@ >>> }; >>> >>> public static void main(String args[]) throws Exception { >>> + Locale.setDefault(Locale.US); >>> Locale defaultLocale = Locale.getDefault(); >>> for (int i=0; i>> final String key = (String) namesMap[i]; >>> diff --git a/test/java/util/logging/SimpleFormatterFormat.java >>> b/test/java/util/logging/SimpleFormatterFormat.java >>> --- a/test/java/util/logging/SimpleFormatterFormat.java >>> +++ b/test/java/util/logging/SimpleFormatterFormat.java >>> @@ -30,6 +30,7 @@ >>> */ >>> >>> import java.io.*; >>> +import java.util.Locale; >>> import java.util.logging.*; >>> import java.util.regex.*; >>> >>> @@ -38,7 +39,8 @@ >>> private static final String origFormat = System.getProperty(key); >>> private static final PrintStream err = System.err; >>> public static void main(String[] args) throws Exception { >>> - try { >>> + Locale.setDefault(Locale.US); >>> + try { >>> File dir = new File(System.getProperty("user.dir", ".")); >>> File log = new File(dir, "simpleformat.txt"); >>> java.nio.file.Files.deleteIfExists(log.toPath()); >>> diff --git a/test/sun/util/logging/SourceClassName.java >>> b/test/sun/util/logging/SourceClassName.java >>> --- a/test/sun/util/logging/SourceClassName.java >>> +++ b/test/sun/util/logging/SourceClassName.java >>> @@ -31,12 +31,14 @@ >>> * @run main/othervm SourceClassName >>> */ >>> >>> +import java.util.Locale; >>> import java.util.logging.*; >>> import java.io.*; >>> import sun.util.logging.PlatformLogger; >>> >>> public class SourceClassName { >>> public static void main(String[] args) throws Exception { >>> + Locale.setDefault(Locale.US); >>> File dir = new File(System.getProperty("user.dir", ".")); >>> File log = new File(dir, "testlog.txt"); >>> PrintStream logps = new PrintStream(log); >>> >> > From aleksej.efimov at oracle.com Tue Nov 5 08:38:44 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 05 Nov 2013 20:38:44 +0400 Subject: RFR: 8027370: (tz) Support tzdata2013h Message-ID: <52791F14.2080305@oracle.com> Hi, Can I have a review for tzdata2013h integration [1]. The webrev link can be located here [2]. The following test sets were executed on build with fix: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter And here is the list of failures: FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% FAILED: java/time/tck/java/time/TCKInstant.java %1% FAILED: java/time/tck/java/time/TCKLocalDate.java %1% FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% FAILED: java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% FAILED: java/util/Calendar/JavatimeTest.java %1% FAILED: sun/util/calendar/zi/TestZoneInfo310.java The group %1% tests failures relates to the JDK-8027622 bug and are expected (actually, it was already resolved in hotspot repo). The 'TestZoneInfo310' test failure is an actual error in current ZoneInfoFile class implementation in JDK. I have filled a bug for this one [3] and will send a separate review with fix later today. [1] https://bugs.openjdk.java.net/browse/JDK-8027370 [2] http://cr.openjdk.java.net/~aefimov/8027370/webrev.00/ [3] https://bugs.openjdk.java.net/browse/JDK-8027848 From francis.andre.kampbell at orange.fr Tue Nov 5 09:11:26 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Tue, 05 Nov 2013 18:11:26 +0100 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <52788897.1000900@oracle.com> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <52788897.1000900@oracle.com> Message-ID: <527926BE.2070600@orange.fr> Hi Michael Le 05/11/2013 06:56, Michael Fang a ?crit : > Hi Francis, > > I am the one coordinating the translation of resource files. I have asked the > translators about the extra space in the past for another file and they replied: > > Please note that this is not an error but a French standard. In French, we > use a space before a colon. That's right, the French grammatical rule is to put a space before and after a colon. But this hold for official French texts, novel litterature and journalistic papers and others where grammatical rules are controlled by French grammar specialist. But here, we are not in this kind of world. it is just an "adaptation" of an US/English message so that a non reader of english prose could understand the message. So no one would blame for not put having a space in front of a colon... Moreover, if you really want to "follow the rules", then rmid : strictly speaking is not a correct french phrase because the word "rmid" has no meaning in French... So please, relax the french localization and remove the space in front of the colon. > > Typically, we do not add jtreg tests to test the translation because the > translation is not "code". Translation is tested with separate in-house test > suites. I am fine with whatever solution that will make the all tests of the jdk pass, would it be to remove the test or use the exclude list for non US locale. What I do not want at all is to check every time a test fails, verify if it fails for using the US locale instead of the default French one. In that case, I suggest you to reconsider the localisation of the test so it pass on a non US platform. Francis > thanks, > > -michael > > On 13?10?31? 09:44 ??, Francis ANDRE wrote: >> Hi Stuart >> >> Please see my comments through the mail >> Le 31/10/2013 22:27, Stuart Marks a ?crit : >>> Hi Francis, >>> >>> Alan Bateman directed me to this patch since it includes changes to the RMI >>> tests, which I maintain. I have a few comments on the changes to these tests. >>> >>>> From: Francis ANDRE >>>> >>>> Following are a list of patch for making the jdk jtreg test suite happy with a >>>> WXP/Cygwin/VS2010 Franch platform. For most of them, the fix consists in >>>> adding >>>> Locale.setDefault(Locale.US); as the first statement in main. >>>> >>>> diff --git a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java >>>> b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java >>>> --- a/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java >>>> +++ b/test/java/rmi/activation/CommandEnvironment/SetChildEnv.java >>>> @@ -238,7 +238,7 @@ >>>> >>>> public synchronized void notifyLine(String s) >>>> { >>>> - if (s != null && s.indexOf("rmid: debugExec") != -1) >>>> + if (s != null && s.indexOf("rmid : debugExec") != -1) >>>> found = s; >>>> } >>>> >>> >>> This is somewhat odd. This section of the test is capturing the output of >>> rmid and is scanning it for a particular string. Why would adding a space be >>> necessary? It turns out that the debugExec lines emitted by rmid are localized: >> If the lines emitted by rmid are localized, then your test "s.indexOf("rmid: >> debugExec") != -1" should be also localized or did I miss something? >>> >>> >>> $ cd jdk/src/share/classes/sun/rmi/server/resources >>> $ grep rmid.exec.command *_*.properties >>> rmid_de.properties:rmid.exec.command=rmid: debugExec: "{0}" wird >>> ausgef\u00FChrt >>> rmid_es.properties:rmid.exec.command=rmid: debugExec: en ejecuci\u00F3n "{0}" >>> rmid_fr.properties:rmid.exec.command=rmid : debugExec : ex\u00E9cution de "{0}" >>> rmid_it.properties:rmid.exec.command=rmid: debugExec: esecuzione di "{0}" in >>> corso >>> rmid_ja.properties:rmid.exec.command=rmid: debugExec: >>> "{0}"\u3092\u5B9F\u884C\u4E2D >>> rmid_ko.properties:rmid.exec.command=rmid: debugExec: "{0}" \uC2E4\uD589 \uC911 >>> rmid_pt_BR.properties:rmid.exec.command=rmid: debugExec: executando "{0}" >>> rmid_sv.properties:rmid.exec.command=rmid: debugExec: k\u00F6r "{0}" >>> rmid_zh_CN.properties:rmid.exec.command=rmid: debugExec: >>> \u6B63\u5728\u8FD0\u884C "{0}" >>> rmid_zh_TW.properties:rmid.exec.command=rmid: debugExec: \u57F7\u884C "{0}" >>> $ grep -B 0 -A 1 rmid.exec.command rmid.properties >>> rmid.exec.command=\ >>> rmid: debugExec: running "{0}" >>> >>> >>> All locales except the French have no space between "rmid" and the trailing >>> colon (":"). It appears that having the space before the colon is proper >>> French usage (at least, the other French localizations all appear similar). >>> But adding the space to the search string will fix the French locale but >>> will break all the other locales. >> From my French perspective -- ie, my mother's language -- , I would not add a >> space between rmid and the colon... >>> >>> Forcing the test to run in the US locale seems preferable to adding logic to >>> deal with different localizations. Since these tests fork JVMs in >>> subprocesses, it's probably necessary to do something special to make sure >>> the sub-JVMs are in the US locale. This probably involves setting an >>> environment variable or a system property. I'm sure others on this list can >>> provide advice. >> I think that the best thing to do is removing the space " " before the colon >> ":" so that your code will work in any localisation. If it is not possible to >> remove this space, then you have to fix the test, taking care the >> localisation you mention in the rmid_fr.properties. Here the report of the test >> >> RMID: starting rmid on port #3882... >> ACTIVATION_LIBRARY: Activation System available after 0 milliseconds >> RMID: finished starting rmid. >> rmid : debugExec : ex?cution de >> "Z:\JDK\jdk8\build\WINDOW~1\images\J2SDK-~1\jre\bin\java >> -Djava.security.manager=default >> -Djava.security.policy=Z:\JDK\jdk8\jdk\test\java\rmi\activation\CommandEnvironment\group.security.policy >> -Dtest.src=Z:\JDK\jdk8\jdk\test\java\rmi\activation\CommandEnvironment >> -Dtest.classes=Z:\JDK\jdk8\build\windows-x86-normal-server-release\testoutput\jdk_rmi\JTwork\classes\0\java\rmi\activation\CommandEnvironment >> -Djava.rmi.server.useCodebaseOnly=false sun.rmi.server.ActivationGroupInit" >> Tue Oct 29 08:15:08 CET 2013:ExecGroup-0:out:Doctor constructed and exported >> Tue Oct 29 08:15:08 CET 2013:ExecGroup-0:out:Doctor will see you now >> TEST FAILED: rmid subprocess produced no recognizable debugExec line >> >>> >>> >>>> diff --git a/test/java/rmi/activation/checkusage/CheckUsage.java >>>> b/test/java/rmi/activation/checkusage/CheckUsage.java >>>> --- a/test/java/rmi/activation/checkusage/CheckUsage.java >>>> +++ b/test/java/rmi/activation/checkusage/CheckUsage.java >>>> @@ -31,12 +31,20 @@ >>>> */ >>>> >>>> import java.io.ByteArrayOutputStream; >>>> +import java.util.HashMap; >>>> +import java.util.Locale; >>>> +import java.util.Map; >>>> >>>> /** >>>> * Make sure that rmid prints out a correct usage statement when run with an >>>> * incorrect command line. >>>> */ >>>> public class CheckUsage { >>>> + private static final Map maps = new HashMap>>> String>(); >>>> + static { >>>> + maps.put(Locale.ENGLISH.getDisplayLanguage(), "runtime flag"); >>>> + maps.put(Locale.FRENCH.getDisplayLanguage(), "indicateur d'ex?cution"); >>>> + } >>>> public static void main(String[] args) { >>>> try { >>>> ByteArrayOutputStream berr = new ByteArrayOutputStream(); >>>> @@ -54,8 +62,9 @@ >>>> String usage = new String(berr.toByteArray()); >>>> >>>> System.err.println("rmid usage: " + usage); >>>> - >>>> - if (usage.indexOf("-J") < 0) { >>>> + >>>> + String jflag = "-J<" + >>>> maps.get(Locale.getDefault().getDisplayLanguage()) + ">"; >>>> + if (usage.indexOf(jflag) < 0) { >>>> TestLibrary.bomb("rmid has incorrect usage message"); >>>> } else { >>>> System.err.println("test passed"); >>> >>> >>> This change looks like the start of a map that includes localized usage >>> messages from various locales. If we were to expand this to other locales, >>> eventually we'd end up duplicating all the localized usage messages into the >>> test code. That seems pretty fragile. >>> >>> As above, this is capturing the output of a subprocess, so it would seem >>> better if the subprocess were forced into the US locale. >>> >>> (In fact, this is kind of a stupid test anyway; all it does is make sure >>> that a usage message gets emitted if an erroneous command-line option is >>> provided. I've been thinking of removing it. It's certainly not worth adding >>> extra logic to handle multiple locales.) >>> >>> -- >>> >>> Do we even support running the test suite in different locales? >> Your test is about the usage message in a localized language, so IMHO, it >> should take care of the localization message otherwise I do not understand >> this code: TestLibrary.bomb("rmid has incorrect usage message"); >>> We test on several platforms as it is; I don't think we'll want to have >>> separate test runs for all eleven (or however many) different localizations. >>> >>> I can see adding code (or test configuration properties or environment >>> variables) to ensure that tests are run in the US locale, unless this is >>> specifically overridden by the test. It doesn't seem appropriate to add >>> locale-specific logic or data structures to the tests, though. >> If purpose of the test is to check the localization message, you would have >> no other choice to use properties like the previous rmid test. >> >> Francis >>> >>> s'marks >>> >>> >>>> diff --git a/test/java/util/Formattable/StockName.java >>>> b/test/java/util/Formattable/StockName.java >>>> --- a/test/java/util/Formattable/StockName.java >>>> +++ b/test/java/util/Formattable/StockName.java >>>> @@ -33,83 +33,90 @@ >>>> import static java.util.FormattableFlags.*; >>>> >>>> public class StockName implements Formattable { >>>> - private String symbol, companyName, frenchCompanyName; >>>> + private String symbol, companyName, frenchCompanyName; >>>> >>>> - public StockName(String symbol, String companyName, >>>> - String frenchCompanyName) >>>> - { >>>> - this.symbol = symbol; >>>> - this.companyName = companyName; >>>> - this.frenchCompanyName = frenchCompanyName; >>>> - } >>>> + public StockName(String symbol, String companyName, String >>>> frenchCompanyName) { >>>> + this.symbol = symbol; >>>> + this.companyName = companyName; >>>> + this.frenchCompanyName = frenchCompanyName; >>>> + } >>>> >>>> - public void formatTo(Formatter fmt, int f, int width, int precision){ >>>> - StringBuilder sb = new StringBuilder(); >>>> + public void formatTo(Formatter fmt, int f, int width, int precision){ >>>> + StringBuilder sb = new StringBuilder(); >>>> >>>> - // decide form of name >>>> - String name = companyName; >>>> - if (fmt.locale().equals(Locale.FRANCE)) >>>> - name = frenchCompanyName; >>>> - boolean alternate = (f & ALTERNATE) == ALTERNATE; >>>> - boolean usesymbol = alternate || (precision != -1 && precision < 10); >>>> - String out = (usesymbol ? symbol : name); >>>> + // decide form of name >>>> + String name = companyName; >>>> + if (fmt.locale().equals(Locale.FRANCE)) >>>> + name = frenchCompanyName; >>>> + boolean alternate = (f & ALTERNATE) == ALTERNATE; >>>> + boolean usesymbol = alternate || (precision != -1 && precision < 10); >>>> + String out = (usesymbol ? symbol : name); >>>> >>>> - // apply precision >>>> - if (precision == -1 || out.length() < precision) { >>>> - // write it all >>>> - sb.append(out); >>>> - } else { >>>> - sb.append(out.substring(0, precision - 1)).append('*'); >>>> - } >>>> + // apply precision >>>> + if (precision == -1 || out.length() < precision) { >>>> + // write it all >>>> + sb.append(out); >>>> + } else { >>>> + sb.append(out.substring(0, precision - 1)).append('*'); >>>> + } >>>> >>>> - // apply width and justification >>>> - int len = sb.length(); >>>> - if (len < width) >>>> - for (int i = 0; i < width - len; i++) >>>> - if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY) >>>> - sb.append(' '); >>>> - else >>>> - sb.insert(0, ' '); >>>> + // apply width and justification >>>> + int len = sb.length(); >>>> + if (len < width) >>>> + for (int i = 0; i < width - len; i++) >>>> + if ((f & LEFT_JUSTIFY) == LEFT_JUSTIFY) >>>> + sb.append(' '); >>>> + else >>>> + sb.insert(0, ' '); >>>> >>>> - fmt.format(sb.toString()); >>>> - } >>>> + fmt.format(sb.toString()); >>>> + } >>>> >>>> - public String toString() { >>>> - return String.format("%s - %s", symbol, companyName); >>>> - } >>>> + public String toString() { >>>> + return String.format("%s - %s", symbol, companyName); >>>> + } >>>> >>>> - public static void main(String [] args) { >>>> - StockName sn = new StockName("HUGE", "Huge Fruit, Inc.", >>>> - "Fruit Titanesque, Inc."); >>>> - CharBuffer cb = CharBuffer.allocate(128); >>>> - Formatter fmt = new Formatter(cb); >>>> + public static void main(String[] args) { >>>> + StockName sn = new StockName("HUGE", "Huge Fruit, Inc.", >>>> + "Fruit Titanesque, Inc."); >>>> + CharBuffer cb = CharBuffer.allocate(128); >>>> + Formatter fmt = new Formatter(cb); >>>> >>>> - fmt.format("%s", sn); // -> "Huge Fruit, Inc." >>>> - test(cb, "Huge Fruit, Inc."); >>>> + if (fmt.locale().equals(Locale.FRANCE)) { >>>> + fmt.format("%s", sn); // -> "Fruit Titanesque, Inc." >>>> + test(cb, "Fruit Titanesque, Inc."); >>>> + } else { >>>> + fmt.format("%s", sn); // -> "Huge Fruit, Inc." >>>> + test(cb, "Huge Fruit, Inc."); >>>> + } >>>> + fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc." >>>> + test(cb, "HUGE - Huge Fruit, Inc."); >>>> >>>> - fmt.format("%s", sn.toString()); // -> "HUGE - Huge Fruit, Inc." >>>> - test(cb, "HUGE - Huge Fruit, Inc."); >>>> + fmt.format("%#s", sn); // -> "HUGE" >>>> + test(cb, "HUGE"); >>>> >>>> - fmt.format("%#s", sn); // -> "HUGE" >>>> - test(cb, "HUGE"); >>>> + fmt.format("%-10.8s", sn); // -> "HUGE " >>>> + test(cb, "HUGE "); >>>> >>>> - fmt.format("%-10.8s", sn); // -> "HUGE " >>>> - test(cb, "HUGE "); >>>> + if (fmt.locale().equals(Locale.FRANCE)) { >>>> + fmt.format("%.12s", sn); // -> "Fruit Titan*" >>>> + test(cb, "Fruit Titan*"); >>>> + } else { >>>> + fmt.format("%.12s", sn); // -> "Huge Fruit,*" >>>> + test(cb, "Huge Fruit,*"); >>>> + } >>>> >>>> - fmt.format("%.12s", sn); // -> "Huge Fruit,*" >>>> - test(cb, "Huge Fruit,*"); >>>> + fmt.format(Locale.FRANCE, "%25s", sn); >>>> + // -> " Fruit Titanesque, Inc." >>>> + test(cb, " Fruit Titanesque, Inc."); >>>> + } >>>> >>>> - fmt.format(Locale.FRANCE, "%25s", sn); >>>> - // -> " Fruit Titanesque, Inc." >>>> - test(cb, " Fruit Titanesque, Inc."); >>>> - } >>>> - >>>> - private static void test(CharBuffer cb, String exp) { >>>> - cb.limit(cb.position()); >>>> - cb.rewind(); >>>> - if (!cb.toString().equals(exp)) >>>> - throw new RuntimeException("expect: '" + exp + "'; got: '" >>>> - + cb.toString() + "'"); >>>> - cb.clear(); >>>> - } >>>> + private static void test(CharBuffer cb, String exp) { >>>> + cb.limit(cb.position()); >>>> + cb.rewind(); >>>> + if (!cb.toString().equals(exp)) >>>> + throw new RuntimeException("expect: '" + exp + "'; got: '" >>>> + + cb.toString() + "'"); >>>> + cb.clear(); >>>> + } >>>> } >>>> diff --git a/test/java/util/ResourceBundle/ResourceBundleTest.java >>>> b/test/java/util/ResourceBundle/ResourceBundleTest.java >>>> --- a/test/java/util/ResourceBundle/ResourceBundleTest.java >>>> +++ b/test/java/util/ResourceBundle/ResourceBundleTest.java >>>> @@ -67,6 +67,7 @@ >>>> >>>> public class ResourceBundleTest extends RBTestFmwk { >>>> public static void main(String[] args) throws Exception { >>>> + Locale.setDefault(Locale.US); >>>> new ResourceBundleTest().run(args); >>>> } >>>> >>>> diff --git >>>> a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>>> b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>>> --- >>>> a/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>>> +++ >>>> b/test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >>>> @@ -45,6 +45,7 @@ >>>> } >>>> >>>> public static void main(String... args) throws Exception { >>>> + Locale.setDefault(Locale.US); >>>> >>>> Locale defaultLocale = Locale.getDefault(); >>>> System.out.println("Default locale is: " + defaultLocale); >>>> diff --git a/test/java/util/logging/LocalizedLevelName.java >>>> b/test/java/util/logging/LocalizedLevelName.java >>>> --- a/test/java/util/logging/LocalizedLevelName.java >>>> +++ b/test/java/util/logging/LocalizedLevelName.java >>>> @@ -49,6 +49,7 @@ >>>> }; >>>> >>>> public static void main(String args[]) throws Exception { >>>> + Locale.setDefault(Locale.US); >>>> Locale defaultLocale = Locale.getDefault(); >>>> for (int i=0; i>>> final String key = (String) namesMap[i]; >>>> diff --git a/test/java/util/logging/SimpleFormatterFormat.java >>>> b/test/java/util/logging/SimpleFormatterFormat.java >>>> --- a/test/java/util/logging/SimpleFormatterFormat.java >>>> +++ b/test/java/util/logging/SimpleFormatterFormat.java >>>> @@ -30,6 +30,7 @@ >>>> */ >>>> >>>> import java.io.*; >>>> +import java.util.Locale; >>>> import java.util.logging.*; >>>> import java.util.regex.*; >>>> >>>> @@ -38,7 +39,8 @@ >>>> private static final String origFormat = System.getProperty(key); >>>> private static final PrintStream err = System.err; >>>> public static void main(String[] args) throws Exception { >>>> - try { >>>> + Locale.setDefault(Locale.US); >>>> + try { >>>> File dir = new File(System.getProperty("user.dir", ".")); >>>> File log = new File(dir, "simpleformat.txt"); >>>> java.nio.file.Files.deleteIfExists(log.toPath()); >>>> diff --git a/test/sun/util/logging/SourceClassName.java >>>> b/test/sun/util/logging/SourceClassName.java >>>> --- a/test/sun/util/logging/SourceClassName.java >>>> +++ b/test/sun/util/logging/SourceClassName.java >>>> @@ -31,12 +31,14 @@ >>>> * @run main/othervm SourceClassName >>>> */ >>>> >>>> +import java.util.Locale; >>>> import java.util.logging.*; >>>> import java.io.*; >>>> import sun.util.logging.PlatformLogger; >>>> >>>> public class SourceClassName { >>>> public static void main(String[] args) throws Exception { >>>> + Locale.setDefault(Locale.US); >>>> File dir = new File(System.getProperty("user.dir", ".")); >>>> File log = new File(dir, "testlog.txt"); >>>> PrintStream logps = new PrintStream(log); >>>> >>> >> > > From Alan.Bateman at oracle.com Tue Nov 5 09:48:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Nov 2013 17:48:18 +0000 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52792A58.2050503@oracle.com> References: <52792A58.2050503@oracle.com> Message-ID: <52792F62.50608@oracle.com> Adding i18n-dev as this is the mailing list where this area is maintained. On 05/11/2013 17:26, Aleksej Efimov wrote: > Hi, > Can I have a review for a 8027848 [1] bug fix . There is unimplemented > functionality related to the future GMT offset changes. > The ZoneInfoFile class doesn't analyses if there is such offset > changes and as a result incorrectly creates the ZoneInfo instance. > It was discovered during the TestZoneInfo310 test execution as part of > tzdata2013h update [3]. > > Thanks, > Aleksej > > [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 > [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 > [3] tzdata2013h review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html > From Alan.Bateman at oracle.com Tue Nov 5 09:50:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Nov 2013 17:50:42 +0000 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <52791F14.2080305@oracle.com> References: <52791F14.2080305@oracle.com> Message-ID: <52792FF2.4050606@oracle.com> On 05/11/2013 16:38, Aleksej Efimov wrote: > Hi, > > Can I have a review for tzdata2013h integration [1]. The webrev link > can be located here [2]. > > The following test sets were executed on build with fix: > test/sun/util/calendar test/java/util/Calendar > test/sun/util/resources/TimeZone test/sun/util/calendar > test/java/util/TimeZone test/java/time test/java/util/Formatter > > And here is the list of failures: > FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% > FAILED: java/time/tck/java/time/TCKInstant.java %1% > FAILED: java/time/tck/java/time/TCKLocalDate.java %1% > FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% > FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% > FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% > FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% > FAILED: java/time/test/java/time/format/TestZoneTextPrinterParser.java > %1% > FAILED: java/util/Calendar/JavatimeTest.java %1% > > FAILED: sun/util/calendar/zi/TestZoneInfo310.java > > > The group %1% tests failures relates to the JDK-8027622 bug and are > expected (actually, it was already resolved in hotspot repo). In another thread, Amy Lu is updating the ProblemList.txt to exclude these tests until the hotspot fix gets to jdk8/tl. For your testing then you could run with -XX:-UseMathExactIntrinsics and check that the all tests related to time and time zones are passing. -Alan. From aleksej.efimov at oracle.com Tue Nov 5 10:07:37 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 05 Nov 2013 22:07:37 +0400 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <52792FF2.4050606@oracle.com> References: <52791F14.2080305@oracle.com> <52792FF2.4050606@oracle.com> Message-ID: <527933E9.3030707@oracle.com> Alan, Thank you for advise. I have executed the same test sets with -XX:-UseMathExactIntrinsics and, as was expected, there is only one failure: sun/util/calendar/zi/TestZoneInfo310.java. -Aleksej On 11/05/2013 09:50 PM, Alan Bateman wrote: > On 05/11/2013 16:38, Aleksej Efimov wrote: >> Hi, >> >> Can I have a review for tzdata2013h integration [1]. The webrev link >> can be located here [2]. >> >> The following test sets were executed on build with fix: >> test/sun/util/calendar test/java/util/Calendar >> test/sun/util/resources/TimeZone test/sun/util/calendar >> test/java/util/TimeZone test/java/time test/java/util/Formatter >> >> And here is the list of failures: >> FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% >> FAILED: java/time/tck/java/time/TCKInstant.java %1% >> FAILED: java/time/tck/java/time/TCKLocalDate.java %1% >> FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% >> FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% >> FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% >> FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% >> FAILED: >> java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% >> FAILED: java/util/Calendar/JavatimeTest.java %1% >> >> FAILED: sun/util/calendar/zi/TestZoneInfo310.java >> >> >> The group %1% tests failures relates to the JDK-8027622 bug and are >> expected (actually, it was already resolved in hotspot repo). > In another thread, Amy Lu is updating the ProblemList.txt to exclude > these tests until the hotspot fix gets to jdk8/tl. For your testing > then you could run with -XX:-UseMathExactIntrinsics and check that the > all tests related to time and time zones are passing. > > -Alan. From xueming.shen at oracle.com Tue Nov 5 10:50:56 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 05 Nov 2013 10:50:56 -0800 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52792A58.2050503@oracle.com> References: <52792A58.2050503@oracle.com> Message-ID: <52793E10.1050903@oracle.com> Aleksej, For better performance (1) the currT should be "static final" so we dont have to access the System.curentTimeMillis() for each TimeZone/ZoneInfo instance. (2) instead of iterating through the standardTransitions(), shouldn't we just check the last one? given it's a sorted list. btw, in theory, the change now uses the "current vm starttime" instead of the "tzdb generated" time. But it should be fine, given ZoneInfo.getRawOffset() will just do a search for the current rawoffset. I may consider to add the "generated time" into the tzdb.dat in the future, if desired. Thanks! -Sherman On 11/05/2013 09:26 AM, Aleksej Efimov wrote: > Hi, > Can I have a review for a 8027848 [1] bug fix . There is unimplemented functionality related to the future GMT offset changes. > The ZoneInfoFile class doesn't analyses if there is such offset changes and as a result incorrectly creates the ZoneInfo instance. > It was discovered during the TestZoneInfo310 test execution as part of tzdata2013h update [3]. > > Thanks, > Aleksej > > [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 > [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 > [3] tzdata2013h review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html From xueming.shen at oracle.com Tue Nov 5 10:58:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 05 Nov 2013 10:58:36 -0800 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52793E10.1050903@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> Message-ID: <52793FDC.5010507@oracle.com> On 11/05/2013 10:50 AM, Xueming Shen wrote: > Aleksej, > > For better performance > (1) the currT should be "static final" so we dont have to access the > System.curentTimeMillis() for each TimeZone/ZoneInfo instance. > (2) instead of iterating through the standardTransitions(), shouldn't we just > check the last one? given it's a sorted list. and maybe this willGMTOffsetChange setting can be done just at line#431. -Sherman > > btw, in theory, the change now uses the "current vm starttime" instead of > the "tzdb generated" time. But it should be fine, given ZoneInfo.getRawOffset() > will just do a search for the current rawoffset. I may consider to add the > "generated time" into the tzdb.dat in the future, if desired. > > Thanks! > -Sherman > > On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >> Hi, >> Can I have a review for a 8027848 [1] bug fix . There is unimplemented functionality related to the future GMT offset changes. >> The ZoneInfoFile class doesn't analyses if there is such offset changes and as a result incorrectly creates the ZoneInfo instance. >> It was discovered during the TestZoneInfo310 test execution as part of tzdata2013h update [3]. >> >> Thanks, >> Aleksej >> >> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >> [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >> [3] tzdata2013h review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html > From aleksej.efimov at oracle.com Tue Nov 5 15:21:19 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 06 Nov 2013 03:21:19 +0400 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52793FDC.5010507@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> <52793FDC.5010507@oracle.com> Message-ID: <52797D6F.3080209@oracle.com> Sherman, Thank you for a quick review. I totally agree with you on all items. Actually, I missed fact that the transitions are sorted. And yes - the change can be done on line #431. The new tested fix can be found here: http://cr.openjdk.java.net/~aefimov/8027848/webrev.01/ -Aleksej On 11/05/2013 10:58 PM, Xueming Shen wrote: > On 11/05/2013 10:50 AM, Xueming Shen wrote: >> Aleksej, >> >> For better performance >> (1) the currT should be "static final" so we dont have to access the >> System.curentTimeMillis() for each TimeZone/ZoneInfo instance. >> (2) instead of iterating through the standardTransitions(), shouldn't >> we just >> check the last one? given it's a sorted list. > > and maybe this willGMTOffsetChange setting can be done just at line#431. > > -Sherman > >> >> btw, in theory, the change now uses the "current vm starttime" >> instead of >> the "tzdb generated" time. But it should be fine, given >> ZoneInfo.getRawOffset() >> will just do a search for the current rawoffset. I may consider to >> add the >> "generated time" into the tzdb.dat in the future, if desired. >> >> Thanks! >> -Sherman >> >> On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >>> Hi, >>> Can I have a review for a 8027848 [1] bug fix . There is >>> unimplemented functionality related to the future GMT offset changes. >>> The ZoneInfoFile class doesn't analyses if there is such offset >>> changes and as a result incorrectly creates the ZoneInfo instance. >>> It was discovered during the TestZoneInfo310 test execution as part >>> of tzdata2013h update [3]. >>> >>> Thanks, >>> Aleksej >>> >>> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >>> [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >>> [3] tzdata2013h review thread: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html >> > From stuart.marks at oracle.com Tue Nov 5 15:27:41 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 05 Nov 2013 15:27:41 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <52786872.7010806@orange.fr> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> Message-ID: <52797EED.1080903@oracle.com> On 11/4/13 7:39 PM, Francis ANDRE wrote: > Stuart. the jtreg jdk test should pass OK on all platforms where OpenJDK could > be build. Yes. On this, we agree. At least, all the tests should pass, on platforms and locales that OpenJDK supports. It looks like localizations are present in OpenJDK for de, es, fr, it, ja, ko, pt_BR, sv, zh_CN, and zh_TW, so all the tests should pass when set to any of these locales. I imagine that your system is set to the French locale, and you observed test failures. You're correct in pointing out that this is a problem. The first thing we need to do is to file a set of bugs on the test failures, and then we need to figure out how to deal with the test failures. (More below.) > So tests that test the localization feature of the jdk should be > localized, otherwise they will failed on non US platform. Two points: first, not all of these tests are tests of localization features of the jdk, and second, localizing the tests is not the correct approach for fixing the tests. To be absolutely clear, in my statement above (and in my previous messages) I'm using "localize" in a very specific fashion. That is, to localize means to modify the code so that its message strings are loaded from a resource bundle, or perhaps from some data structure, instead of being hardcoded. (There are probably other kinds of localization, but in this context, we're mainly concerned with message strings.) In general, we don't localize tests. In the specific cases of the RMI CheckUsage and SetChildEnv tests, modifying them to use different message strings based on the current locale is unacceptable. >> Bottom line is that I do not think it makes sense to localize these tests. > Stuart, as I already mention before, what is important is that the jdk tests > pass OK whatever country there are run. So those specific tests that fails even > if the localization is preset to Locale.US must be corrected to pass in non US > country or removed. Our statements aren't actually contradicting each other. I agree that the failing tests need to be corrected or removed. I'm also stating the localizing the tests is not the way to correct them. They must be dealt with some other way. * * * OK, let's step back from this and take inventory. The patch contained fixes for the following tests, presumably because they failed when run in the French locale. For each failing test, what should be done about it? test/java/rmi/activation/CommandEnvironment/SetChildEnv.java - JDK-8027873: fix RMI test library to run rmid in the US locale test/java/rmi/activation/checkusage/CheckUsage.java - JDK-8027810: this test should be removed test/java/util/Formattable/StockName.java test/java/util/ResourceBundle/ResourceBundleTest.java test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java test/java/util/logging/LocalizedLevelName.java test/java/util/logging/SimpleFormatterFormat.java test/sun/util/logging/SourceClassName.java - Internationalization folks, what should be done about these tests? s'marks From naoto.sato at oracle.com Tue Nov 5 15:43:51 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 05 Nov 2013 15:43:51 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <52797EED.1080903@oracle.com> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> <52797EED.1080903@oracle.com> Message-ID: <527982B7.5040306@oracle.com> For those tests that are locale sensitive, basic approach should be like: Locale defaultLocale = Locale.getDefault(); try { Locale.setDefault(); } finally { Locale.setDefault(defaultLocale); } However, it looks to me that those tests in ResourceBundle are already capable of whatever the default locale is, so the test failure needs to be investigated and fixed, not just by setting the locale to Locale.US. Naoto On 11/5/13, 3:27 PM, Stuart Marks wrote: > > > On 11/4/13 7:39 PM, Francis ANDRE wrote: >> Stuart. the jtreg jdk test should pass OK on all platforms where >> OpenJDK could >> be build. > > Yes. On this, we agree. At least, all the tests should pass, on > platforms and locales that OpenJDK supports. It looks like localizations > are present in OpenJDK for de, es, fr, it, ja, ko, pt_BR, sv, zh_CN, and > zh_TW, so all the tests should pass when set to any of these locales. > > I imagine that your system is set to the French locale, and you observed > test failures. You're correct in pointing out that this is a problem. > The first thing we need to do is to file a set of bugs on the test > failures, and then we need to figure out how to deal with the test > failures. (More below.) > >> So tests that test the localization feature of the jdk should be >> localized, otherwise they will failed on non US platform. > > Two points: first, not all of these tests are tests of localization > features of the jdk, and second, localizing the tests is not the correct > approach for fixing the tests. > > To be absolutely clear, in my statement above (and in my previous > messages) I'm using "localize" in a very specific fashion. That is, to > localize means to modify the code so that its message strings are loaded > from a resource bundle, or perhaps from some data structure, instead of > being hardcoded. (There are probably other kinds of localization, but in > this context, we're mainly concerned with message strings.) > > In general, we don't localize tests. In the specific cases of the RMI > CheckUsage and SetChildEnv tests, modifying them to use different > message strings based on the current locale is unacceptable. > >>> Bottom line is that I do not think it makes sense to localize these >>> tests. >> Stuart, as I already mention before, what is important is that the jdk >> tests >> pass OK whatever country there are run. So those specific tests that >> fails even >> if the localization is preset to Locale.US must be corrected to pass >> in non US >> country or removed. > > Our statements aren't actually contradicting each other. I agree that > the failing tests need to be corrected or removed. I'm also stating the > localizing the tests is not the way to correct them. They must be dealt > with some other way. > > * * * > > OK, let's step back from this and take inventory. The patch contained > fixes for the following tests, presumably because they failed when run > in the French locale. For each failing test, what should be done about it? > > test/java/rmi/activation/CommandEnvironment/SetChildEnv.java > - JDK-8027873: fix RMI test library to run rmid in the US locale > > test/java/rmi/activation/checkusage/CheckUsage.java > - JDK-8027810: this test should be removed > > test/java/util/Formattable/StockName.java > test/java/util/ResourceBundle/ResourceBundleTest.java > test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java > test/java/util/logging/LocalizedLevelName.java > test/java/util/logging/SimpleFormatterFormat.java > test/sun/util/logging/SourceClassName.java > > - Internationalization folks, what should be done about these tests? > > > s'marks From xueming.shen at oracle.com Wed Nov 6 09:18:57 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 06 Nov 2013 09:18:57 -0800 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <52797D6F.3080209@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> <52793FDC.5010507@oracle.com> <52797D6F.3080209@oracle.com> Message-ID: <527A7A01.3010301@oracle.com> Looks fine. thanks! -Sherman On 11/05/2013 03:21 PM, Aleksej Efimov wrote: > Sherman, > Thank you for a quick review. I totally agree with you on all items. > Actually, I missed fact that the transitions are sorted. And yes - the change can be done on line #431. > The new tested fix can be found here: http://cr.openjdk.java.net/~aefimov/8027848/webrev.01/ > > -Aleksej > > On 11/05/2013 10:58 PM, Xueming Shen wrote: >> On 11/05/2013 10:50 AM, Xueming Shen wrote: >>> Aleksej, >>> >>> For better performance >>> (1) the currT should be "static final" so we dont have to access the >>> System.curentTimeMillis() for each TimeZone/ZoneInfo instance. >>> (2) instead of iterating through the standardTransitions(), shouldn't we just >>> check the last one? given it's a sorted list. >> >> and maybe this willGMTOffsetChange setting can be done just at line#431. >> >> -Sherman >> >>> >>> btw, in theory, the change now uses the "current vm starttime" instead of >>> the "tzdb generated" time. But it should be fine, given ZoneInfo.getRawOffset() >>> will just do a search for the current rawoffset. I may consider to add the >>> "generated time" into the tzdb.dat in the future, if desired. >>> >>> Thanks! >>> -Sherman >>> >>> On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >>>> Hi, >>>> Can I have a review for a 8027848 [1] bug fix . There is unimplemented functionality related to the future GMT offset changes. >>>> The ZoneInfoFile class doesn't analyses if there is such offset changes and as a result incorrectly creates the ZoneInfo instance. >>>> It was discovered during the TestZoneInfo310 test execution as part of tzdata2013h update [3]. >>>> >>>> Thanks, >>>> Aleksej >>>> >>>> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >>>> [2] Proposed fix: http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >>>> [3] tzdata2013h review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html >>> >> > From naoto.sato at oracle.com Wed Nov 6 09:47:16 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 06 Nov 2013 09:47:16 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <5279E230.5080802@orange.fr> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> <52797EED.1080903@oracle.com> <527982B7.5040306@oracle.com> <5279E230.5080802@orange.fr> Message-ID: <527A80A4.4040108@oracle.com> Thank you, Francis. I created the following CR for those ResourceBundle test failures: https://bugs.openjdk.java.net/browse/JDK-8027930 Naoto On 11/5/13 10:31 PM, Francis ANDRE wrote: > HI > > To add a little bit more of clarity for the i18n problems in the > ResourceBundle tests, joined is an extract from the log of their > failures before I fixed them for the non US Locale case. Sorry for not > having joined this log before. > > HTH > > Francis From aleksej.efimov at oracle.com Wed Nov 6 11:11:46 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 06 Nov 2013 23:11:46 +0400 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <527933E9.3030707@oracle.com> References: <52791F14.2080305@oracle.com> <52792FF2.4050606@oracle.com> <527933E9.3030707@oracle.com> Message-ID: <527A9472.9070403@oracle.com> Hi, We have a fix for JDK-8027848 and it was approved in parallel thread. With '-XX:-UseMathExactIntrinsics' tests run flag and applied fix for JDK-8027848 all tests from the following test sets are passing: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter. I suppose, that we're good to go with this change, unless there are some comments or issues. -Aleksej On 11/05/2013 10:07 PM, Aleksej Efimov wrote: > Alan, > Thank you for advise. > I have executed the same test sets with -XX:-UseMathExactIntrinsics > and, as was expected, there is only one failure: > sun/util/calendar/zi/TestZoneInfo310.java. > > -Aleksej > > On 11/05/2013 09:50 PM, Alan Bateman wrote: >> On 05/11/2013 16:38, Aleksej Efimov wrote: >>> Hi, >>> >>> Can I have a review for tzdata2013h integration [1]. The webrev link >>> can be located here [2]. >>> >>> The following test sets were executed on build with fix: >>> test/sun/util/calendar test/java/util/Calendar >>> test/sun/util/resources/TimeZone test/sun/util/calendar >>> test/java/util/TimeZone test/java/time test/java/util/Formatter >>> >>> And here is the list of failures: >>> FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% >>> FAILED: java/time/tck/java/time/TCKInstant.java %1% >>> FAILED: java/time/tck/java/time/TCKLocalDate.java %1% >>> FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% >>> FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% >>> FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% >>> FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% >>> FAILED: >>> java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% >>> FAILED: java/util/Calendar/JavatimeTest.java %1% >>> >>> FAILED: sun/util/calendar/zi/TestZoneInfo310.java >>> >>> >>> The group %1% tests failures relates to the JDK-8027622 bug and are >>> expected (actually, it was already resolved in hotspot repo). >> In another thread, Amy Lu is updating the ProblemList.txt to exclude >> these tests until the hotspot fix gets to jdk8/tl. For your testing >> then you could run with -XX:-UseMathExactIntrinsics and check that >> the all tests related to time and time zones are passing. >> >> -Alan. > From aleksej.efimov at oracle.com Wed Nov 6 11:15:41 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 06 Nov 2013 23:15:41 +0400 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <527A7A01.3010301@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> <52793FDC.5010507@oracle.com> <52797D6F.3080209@oracle.com> <527A7A01.3010301@oracle.com> Message-ID: <527A955D.8090407@oracle.com> Sherman, thank you for reviewing it! -Aleksej On 11/06/2013 09:18 PM, Xueming Shen wrote: > Looks fine. > > thanks! > -Sherman > > On 11/05/2013 03:21 PM, Aleksej Efimov wrote: >> Sherman, >> Thank you for a quick review. I totally agree with you on all items. >> Actually, I missed fact that the transitions are sorted. And yes - >> the change can be done on line #431. >> The new tested fix can be found here: >> http://cr.openjdk.java.net/~aefimov/8027848/webrev.01/ >> >> >> -Aleksej >> >> On 11/05/2013 10:58 PM, Xueming Shen wrote: >>> On 11/05/2013 10:50 AM, Xueming Shen wrote: >>>> Aleksej, >>>> >>>> For better performance >>>> (1) the currT should be "static final" so we dont have to access the >>>> System.curentTimeMillis() for each TimeZone/ZoneInfo instance. >>>> (2) instead of iterating through the standardTransitions(), >>>> shouldn't we just >>>> check the last one? given it's a sorted list. >>> >>> and maybe this willGMTOffsetChange setting can be done just at >>> line#431. >>> >>> -Sherman >>> >>>> >>>> btw, in theory, the change now uses the "current vm starttime" >>>> instead of >>>> the "tzdb generated" time. But it should be fine, given >>>> ZoneInfo.getRawOffset() >>>> will just do a search for the current rawoffset. I may consider to >>>> add the >>>> "generated time" into the tzdb.dat in the future, if desired. >>>> >>>> Thanks! >>>> -Sherman >>>> >>>> On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >>>>> Hi, >>>>> Can I have a review for a 8027848 [1] bug fix . There is >>>>> unimplemented functionality related to the future GMT offset changes. >>>>> The ZoneInfoFile class doesn't analyses if there is such offset >>>>> changes and as a result incorrectly creates the ZoneInfo instance. >>>>> It was discovered during the TestZoneInfo310 test execution as >>>>> part of tzdata2013h update [3]. >>>>> >>>>> Thanks, >>>>> Aleksej >>>>> >>>>> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >>>>> [2] Proposed fix: >>>>> http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >>>>> [3] tzdata2013h review thread: >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html >>>> >>> >> > From francis.andre.kampbell at orange.fr Tue Nov 5 22:31:12 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Wed, 06 Nov 2013 07:31:12 +0100 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <527982B7.5040306@oracle.com> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> <52797EED.1080903@oracle.com> <527982B7.5040306@oracle.com> Message-ID: <5279E230.5080802@orange.fr> HI To add a little bit more of clarity for the i18n problems in the ResourceBundle tests, joined is an extract from the log of their failures before I fixed them for the non US Locale case. Sorry for not having joined this log before. HTH Francis Le 06/11/2013 00:43, Naoto Sato a ?crit : > For those tests that are locale sensitive, basic approach should be like: > > Locale defaultLocale = Locale.getDefault(); > try { > Locale.setDefault(); > > > > } finally { > Locale.setDefault(defaultLocale); > } > > However, it looks to me that those tests in ResourceBundle are already capable > of whatever the default locale is, so the test failure needs to be > investigated and fixed, not just by setting the locale to Locale.US. > > Naoto > > On 11/5/13, 3:27 PM, Stuart Marks wrote: >> >> >> On 11/4/13 7:39 PM, Francis ANDRE wrote: >>> Stuart. the jtreg jdk test should pass OK on all platforms where >>> OpenJDK could >>> be build. >> >> Yes. On this, we agree. At least, all the tests should pass, on >> platforms and locales that OpenJDK supports. It looks like localizations >> are present in OpenJDK for de, es, fr, it, ja, ko, pt_BR, sv, zh_CN, and >> zh_TW, so all the tests should pass when set to any of these locales. >> >> I imagine that your system is set to the French locale, and you observed >> test failures. You're correct in pointing out that this is a problem. >> The first thing we need to do is to file a set of bugs on the test >> failures, and then we need to figure out how to deal with the test >> failures. (More below.) >> >>> So tests that test the localization feature of the jdk should be >>> localized, otherwise they will failed on non US platform. >> >> Two points: first, not all of these tests are tests of localization >> features of the jdk, and second, localizing the tests is not the correct >> approach for fixing the tests. >> >> To be absolutely clear, in my statement above (and in my previous >> messages) I'm using "localize" in a very specific fashion. That is, to >> localize means to modify the code so that its message strings are loaded >> from a resource bundle, or perhaps from some data structure, instead of >> being hardcoded. (There are probably other kinds of localization, but in >> this context, we're mainly concerned with message strings.) >> >> In general, we don't localize tests. In the specific cases of the RMI >> CheckUsage and SetChildEnv tests, modifying them to use different >> message strings based on the current locale is unacceptable. >> >>>> Bottom line is that I do not think it makes sense to localize these >>>> tests. >>> Stuart, as I already mention before, what is important is that the jdk >>> tests >>> pass OK whatever country there are run. So those specific tests that >>> fails even >>> if the localization is preset to Locale.US must be corrected to pass >>> in non US >>> country or removed. >> >> Our statements aren't actually contradicting each other. I agree that >> the failing tests need to be corrected or removed. I'm also stating the >> localizing the tests is not the way to correct them. They must be dealt >> with some other way. >> >> * * * >> >> OK, let's step back from this and take inventory. The patch contained >> fixes for the following tests, presumably because they failed when run >> in the French locale. For each failing test, what should be done about it? >> >> test/java/rmi/activation/CommandEnvironment/SetChildEnv.java >> - JDK-8027873: fix RMI test library to run rmid in the US locale >> >> test/java/rmi/activation/checkusage/CheckUsage.java >> - JDK-8027810: this test should be removed >> >> test/java/util/Formattable/StockName.java >> test/java/util/ResourceBundle/ResourceBundleTest.java >> test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java >> test/java/util/logging/LocalizedLevelName.java >> test/java/util/logging/SimpleFormatterFormat.java >> test/sun/util/logging/SourceClassName.java >> >> - Internationalization folks, what should be done about these tests? >> >> >> s'marks > > From naoto.sato at oracle.com Wed Nov 6 14:36:11 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 06 Nov 2013 14:36:11 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <527A80A4.4040108@oracle.com> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> <52797EED.1080903@oracle.com> <527982B7.5040306@oracle.com> <5279E230.5080802@orange.fr> <527A80A4.4040108@oracle.com> Message-ID: <527AC45B.5040707@oracle.com> And here is the proposed webrev. Please review: http://cr.openjdk.java.net/~naoto/8027930/webrev.00/ Naoto On 11/6/13 9:47 AM, Naoto Sato wrote: > Thank you, Francis. I created the following CR for those ResourceBundle > test failures: > > https://bugs.openjdk.java.net/browse/JDK-8027930 > > Naoto > > On 11/5/13 10:31 PM, Francis ANDRE wrote: >> HI >> >> To add a little bit more of clarity for the i18n problems in the >> ResourceBundle tests, joined is an extract from the log of their >> failures before I fixed them for the non US Locale case. Sorry for not >> having joined this log before. >> >> HTH >> >> Francis From stuart.marks at oracle.com Wed Nov 6 15:24:08 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 06 Nov 2013 15:24:08 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <5279E230.5080802@orange.fr> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> <52797EED.1080903@oracle.com> <527982B7.5040306@oracle.com> <5279E230.5080802@orange.fr> Message-ID: <527ACF98.3020008@oracle.com> On 11/5/13 10:31 PM, Francis ANDRE wrote: > To add a little bit more of clarity for the i18n problems in the ResourceBundle > tests, joined is an extract from the log of their failures before I fixed them > for the non US Locale case. Sorry for not having joined this log before. By the way, it looks like the i18n-dev mailing list deletes attachments. Naoto and I received the attachment with the error log, since we were both direct recipients. It looks like Naoto has attached the log to this bug report: https://bugs.openjdk.java.net/browse/JDK-8027930 (This message is mainly for anyone reading the archives who wonders where to find the attachment.) s'marks From stuart.marks at oracle.com Wed Nov 6 16:11:22 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 06 Nov 2013 16:11:22 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <527AC45B.5040707@oracle.com> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> <52797EED.1080903@oracle.com> <527982B7.5040306@oracle.com> <5279E230.5080802@orange.fr> <527A80A4.4040108@oracle.com> <527AC45B.5040707@oracle.com> Message-ID: <527ADAAA.1000601@oracle.com> Hi Naoto, The changes look sensible, though I'm not an expert in the ResourceBundle API. I did notice though that in ResourceBundleTest.java there is a static import of java.util.ResourceBundle.Control. Does it need to be a static import? Surprisingly, it seems to compile either way. s'marks On 11/6/13 2:36 PM, Naoto Sato wrote: > And here is the proposed webrev. Please review: > > http://cr.openjdk.java.net/~naoto/8027930/webrev.00/ > > Naoto > > On 11/6/13 9:47 AM, Naoto Sato wrote: >> Thank you, Francis. I created the following CR for those ResourceBundle >> test failures: >> >> https://bugs.openjdk.java.net/browse/JDK-8027930 >> >> Naoto >> >> On 11/5/13 10:31 PM, Francis ANDRE wrote: >>> HI >>> >>> To add a little bit more of clarity for the i18n problems in the >>> ResourceBundle tests, joined is an extract from the log of their >>> failures before I fixed them for the non US Locale case. Sorry for not >>> having joined this log before. >>> >>> HTH >>> >>> Francis From naoto.sato at oracle.com Wed Nov 6 16:33:25 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 06 Nov 2013 16:33:25 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <527ADAAA.1000601@oracle.com> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> <52797EED.1080903@oracle.com> <527982B7.5040306@oracle.com> <5279E230.5080802@orange.fr> <527A80A4.4040108@oracle.com> <527AC45B.5040707@oracle.com> <527ADAAA.1000601@oracle.com> Message-ID: <527ADFD5.3040208@oracle.com> Thank you for the review, Stuart. I just wanted to get rid of "Control" in front of "FORMAT_DEFAULT", but silly me, I did not do that! And it does not seem to make much sense using static import just for that purpose. I will remove "static" from the proposed fix. Naoto On 11/6/13 4:11 PM, Stuart Marks wrote: > Hi Naoto, > > The changes look sensible, though I'm not an expert in the > ResourceBundle API. > > I did notice though that in ResourceBundleTest.java there is a static > import of java.util.ResourceBundle.Control. Does it need to be a static > import? Surprisingly, it seems to compile either way. > > s'marks > > > On 11/6/13 2:36 PM, Naoto Sato wrote: >> And here is the proposed webrev. Please review: >> >> http://cr.openjdk.java.net/~naoto/8027930/webrev.00/ >> >> Naoto >> >> On 11/6/13 9:47 AM, Naoto Sato wrote: >>> Thank you, Francis. I created the following CR for those ResourceBundle >>> test failures: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8027930 >>> >>> Naoto >>> >>> On 11/5/13 10:31 PM, Francis ANDRE wrote: >>>> HI >>>> >>>> To add a little bit more of clarity for the i18n problems in the >>>> ResourceBundle tests, joined is an extract from the log of their >>>> failures before I fixed them for the non US Locale case. Sorry for not >>>> having joined this log before. >>>> >>>> HTH >>>> >>>> Francis From yong.huang at oracle.com Wed Nov 6 21:54:29 2013 From: yong.huang at oracle.com (Yong Huang) Date: Thu, 07 Nov 2013 13:54:29 +0800 Subject: Review Request - 8027695: There should be a space before % sign in Swedish locale Message-ID: <527B2B15.6020600@oracle.com> Hello, Please review the fix of https://bugs.openjdk.java.net/browse/JDK-8027695 The webrev is http://cr.openjdk.java.net/~yhuang/8027695/webrev.00/ thanks, Yong From francis.andre.kampbell at orange.fr Wed Nov 6 22:50:22 2013 From: francis.andre.kampbell at orange.fr (Francis ANDRE) Date: Thu, 07 Nov 2013 07:50:22 +0100 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <527AC45B.5040707@oracle.com> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> <52797EED.1080903@oracle.com> <527982B7.5040306@oracle.com> <5279E230.5080802@orange.fr> <527A80A4.4040108@oracle.com> <527AC45B.5040707@oracle.com> Message-ID: <527B382E.4050903@orange.fr> Hi Naoto And what will happen to the other non US locale problem? Will they get fix also? Francis Le 06/11/2013 23:36, Naoto Sato a ?crit : > And here is the proposed webrev. Please review: > > http://cr.openjdk.java.net/~naoto/8027930/webrev.00/ > > Naoto > > On 11/6/13 9:47 AM, Naoto Sato wrote: >> Thank you, Francis. I created the following CR for those ResourceBundle >> test failures: >> >> https://bugs.openjdk.java.net/browse/JDK-8027930 >> >> Naoto >> >> On 11/5/13 10:31 PM, Francis ANDRE wrote: >>> HI >>> >>> To add a little bit more of clarity for the i18n problems in the >>> ResourceBundle tests, joined is an extract from the log of their >>> failures before I fixed them for the non US Locale case. Sorry for not >>> having joined this log before. >>> >>> HTH >>> >>> Francis > From naoto.sato at oracle.com Thu Nov 7 08:42:30 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 07 Nov 2013 08:42:30 -0800 Subject: [8]: diff patch for jdk test on a non US platform In-Reply-To: <527B382E.4050903@orange.fr> References: <527295D9.8050907@orange.fr> <52729A53.1010201@oracle.com> <5272CB33.8090501@oracle.com> <527331AE.9080001@orange.fr> <527848AE.6010405@oracle.com> <52786872.7010806@orange.fr> <52797EED.1080903@oracle.com> <527982B7.5040306@oracle.com> <5279E230.5080802@orange.fr> <527A80A4.4040108@oracle.com> <527AC45B.5040707@oracle.com> <527B382E.4050903@orange.fr> Message-ID: <527BC2F6.3010306@oracle.com> Hi Francis, It will work as the test case expects. The issue here was that the test case did not expect the default locale can be French. The test case itself provides French resource bundles, so it was unexpectedly loaded in such a case and did not fall back to the base resource bundle. Naoto On 11/6/13 10:50 PM, Francis ANDRE wrote: > Hi Naoto > > And what will happen to the other non US locale problem? Will they get > fix also? > > Francis > > > Le 06/11/2013 23:36, Naoto Sato a ?crit : >> And here is the proposed webrev. Please review: >> >> http://cr.openjdk.java.net/~naoto/8027930/webrev.00/ >> >> Naoto >> >> On 11/6/13 9:47 AM, Naoto Sato wrote: >>> Thank you, Francis. I created the following CR for those ResourceBundle >>> test failures: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8027930 >>> >>> Naoto >>> >>> On 11/5/13 10:31 PM, Francis ANDRE wrote: >>>> HI >>>> >>>> To add a little bit more of clarity for the i18n problems in the >>>> ResourceBundle tests, joined is an extract from the log of their >>>> failures before I fixed them for the non US Locale case. Sorry for not >>>> having joined this log before. >>>> >>>> HTH >>>> >>>> Francis >> > From naoto.sato at oracle.com Thu Nov 7 11:46:14 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 07 Nov 2013 11:46:14 -0800 Subject: Review Request - 8027695: There should be a space before % sign in Swedish locale In-Reply-To: <527B2B15.6020600@oracle.com> References: <527B2B15.6020600@oracle.com> Message-ID: <527BEE06.9050802@oracle.com> Looks good. Naoto On 11/6/13 9:54 PM, Yong Huang wrote: > Hello, > > Please review the fix of https://bugs.openjdk.java.net/browse/JDK-8027695 > > The webrev is http://cr.openjdk.java.net/~yhuang/8027695/webrev.00/ > > thanks, > Yong From michael.fang at oracle.com Thu Nov 7 15:36:42 2013 From: michael.fang at oracle.com (Michael Fang) Date: Thu, 07 Nov 2013 15:36:42 -0800 Subject: Review Request - 8027695: There should be a space before % sign in Swedish locale In-Reply-To: <527BEE06.9050802@oracle.com> References: <527B2B15.6020600@oracle.com> <527BEE06.9050802@oracle.com> Message-ID: <527C240A.8010801@oracle.com> It also looks good to me. thanks, -michael On 13?11?07? 11:46 ??, Naoto Sato wrote: > Looks good. > > Naoto > > On 11/6/13 9:54 PM, Yong Huang wrote: >> Hello, >> >> Please review the fix of >> https://bugs.openjdk.java.net/browse/JDK-8027695 >> >> The webrev is http://cr.openjdk.java.net/~yhuang/8027695/webrev.00/ >> >> thanks, >> Yong From Alan.Bateman at oracle.com Fri Nov 8 01:24:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Nov 2013 09:24:05 +0000 Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527C5D7F.2000102@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> <527C5D7F.2000102@oracle.com> Message-ID: <527CADB5.2060702@oracle.com> On 08/11/2013 03:41, Patrick Zhang wrote: > Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. > Now the webrev and result are attached. Please help to review. > After checking the scripts in java.util, most of scripts have been > finished in 8003890. So the webrev only change 2 rest files. > > webrev: > http://cr.openjdk.java.net/~pzhang/8019502/webrev/ > > result: > http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr > http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr cc'ing i18n-dev as that is where Calendar (and its tests) are maintained. The change look okay to me but I wonder if perhaps you have the wrong bug number. JDK-8019502 is a confused bug but I think it was originally intended to be an audit of the tests that use Runtime.exec or ProcessBuilder to see if they should be changed to pass the options through. I just mention it as I suspect you might need to create a new bug for this and then split up JDK-8019502 into other tasks. -Alan From aleksej.efimov at oracle.com Fri Nov 8 03:44:47 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Fri, 08 Nov 2013 15:44:47 +0400 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <527A9472.9070403@oracle.com> References: <52791F14.2080305@oracle.com> <52792FF2.4050606@oracle.com> <527933E9.3030707@oracle.com> <527A9472.9070403@oracle.com> Message-ID: <527CCEAF.5020404@oracle.com> Hi, Can I ask reviewers to look at this fix? As was mentioned, the testing issues described in request were resolved. Thanks in advance, Aleksej On 11/06/2013 11:11 PM, Aleksej Efimov wrote: > Hi, > We have a fix for JDK-8027848 and it was approved in parallel thread. > With '-XX:-UseMathExactIntrinsics' tests run flag and applied fix for > JDK-8027848 all tests from the following test sets are passing: > test/sun/util/calendar test/java/util/Calendar > test/sun/util/resources/TimeZone test/sun/util/calendar > test/java/util/TimeZone test/java/time test/java/util/Formatter. > I suppose, that we're good to go with this change, unless there are > some comments or issues. > > -Aleksej > > On 11/05/2013 10:07 PM, Aleksej Efimov wrote: >> Alan, >> Thank you for advise. >> I have executed the same test sets with -XX:-UseMathExactIntrinsics >> and, as was expected, there is only one failure: >> sun/util/calendar/zi/TestZoneInfo310.java. >> >> -Aleksej >> >> On 11/05/2013 09:50 PM, Alan Bateman wrote: >>> On 05/11/2013 16:38, Aleksej Efimov wrote: >>>> Hi, >>>> >>>> Can I have a review for tzdata2013h integration [1]. The webrev >>>> link can be located here [2]. >>>> >>>> The following test sets were executed on build with fix: >>>> test/sun/util/calendar test/java/util/Calendar >>>> test/sun/util/resources/TimeZone test/sun/util/calendar >>>> test/java/util/TimeZone test/java/time test/java/util/Formatter >>>> >>>> And here is the list of failures: >>>> FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% >>>> FAILED: java/time/tck/java/time/TCKInstant.java %1% >>>> FAILED: java/time/tck/java/time/TCKLocalDate.java %1% >>>> FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% >>>> FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% >>>> FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% >>>> FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% >>>> FAILED: >>>> java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% >>>> FAILED: java/util/Calendar/JavatimeTest.java %1% >>>> >>>> FAILED: sun/util/calendar/zi/TestZoneInfo310.java >>>> >>>> >>>> The group %1% tests failures relates to the JDK-8027622 bug and are >>>> expected (actually, it was already resolved in hotspot repo). >>> In another thread, Amy Lu is updating the ProblemList.txt to exclude >>> these tests until the hotspot fix gets to jdk8/tl. For your testing >>> then you could run with -XX:-UseMathExactIntrinsics and check that >>> the all tests related to time and time zones are passing. >>> >>> -Alan. >> > From david.holmes at oracle.com Fri Nov 8 04:43:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Nov 2013 04:43:43 -0800 (PST) Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527CB943.8040207@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> <527C5D7F.2000102@oracle.com> <527CADB5.2060702@oracle.com> <527CB943.8040207@oracle.com> Message-ID: <527CDC7F.5020703@oracle.com> On 8/11/2013 8:13 PM, Patrick Zhang wrote: > Hi Alan, > > I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to hold it. My understanding is that 8019502 was originally covering this issue for a broad range of tests across different areas. They were then split out into different CRs for different groups of tests. The remaining tests in the original bug were then handed to Patrick. David > Regards > Patrick > > On 11/8/13 5:24 PM, Alan Bateman wrote: >> On 08/11/2013 03:41, Patrick Zhang wrote: >>> Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. >>> Now the webrev and result are attached. Please help to review. >>> After checking the scripts in java.util, most of scripts have been >>> finished in 8003890. So the webrev only change 2 rest files. >>> >>> webrev: >>> http://cr.openjdk.java.net/~pzhang/8019502/webrev/ >>> >>> result: >>> http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr >>> http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr >> cc'ing i18n-dev as that is where Calendar (and its tests) are maintained. >> >> The change look okay to me but I wonder if perhaps you have the wrong >> bug number. JDK-8019502 is a confused bug but I think it was >> originally intended to be an audit of the tests that use Runtime.exec >> or ProcessBuilder to see if they should be changed to pass the options >> through. I just mention it as I suspect you might need to create a new >> bug for this and then split up JDK-8019502 into other tasks. >> >> -Alan From xueming.shen at oracle.com Fri Nov 8 08:42:12 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 08 Nov 2013 08:42:12 -0800 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <52791F14.2080305@oracle.com> References: <52791F14.2080305@oracle.com> Message-ID: <527D1464.3080508@oracle.com> looks fine. I would assume you've also run the corresponding tests at test/closed repo. -Sherman On 11/5/2013 8:38 AM, Aleksej Efimov wrote: > Hi, > > Can I have a review for tzdata2013h integration [1]. The webrev link can be located here [2]. > > The following test sets were executed on build with fix: > test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter > > And here is the list of failures: > FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% > FAILED: java/time/tck/java/time/TCKInstant.java %1% > FAILED: java/time/tck/java/time/TCKLocalDate.java %1% > FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% > FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% > FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% > FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% > FAILED: java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% > FAILED: java/util/Calendar/JavatimeTest.java %1% > > FAILED: sun/util/calendar/zi/TestZoneInfo310.java > > > The group %1% tests failures relates to the JDK-8027622 bug and are expected (actually, it was already resolved in hotspot repo). > The 'TestZoneInfo310' test failure is an actual error in current ZoneInfoFile class implementation in JDK. I have filled a bug for this one [3] and will send a separate review with fix later today. > > [1] https://bugs.openjdk.java.net/browse/JDK-8027370 > [2] http://cr.openjdk.java.net/~aefimov/8027370/webrev.00/ > [3] https://bugs.openjdk.java.net/browse/JDK-8027848 From patrick.zhang at oracle.com Fri Nov 8 02:13:23 2013 From: patrick.zhang at oracle.com (Patrick Zhang) Date: Fri, 08 Nov 2013 18:13:23 +0800 Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527CADB5.2060702@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> <527C5D7F.2000102@oracle.com> <527CADB5.2060702@oracle.com> Message-ID: <527CB943.8040207@oracle.com> Hi Alan, I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to hold it. Regards Patrick On 11/8/13 5:24 PM, Alan Bateman wrote: > On 08/11/2013 03:41, Patrick Zhang wrote: >> Sorry, I have some problems to connect to cr.openjdk.java.net yesterday. >> Now the webrev and result are attached. Please help to review. >> After checking the scripts in java.util, most of scripts have been >> finished in 8003890. So the webrev only change 2 rest files. >> >> webrev: >> http://cr.openjdk.java.net/~pzhang/8019502/webrev/ >> >> result: >> http://cr.openjdk.java.net/~pzhang/8019502/GenericTimeZoneNamesTest.jtr >> http://cr.openjdk.java.net/~pzhang/8019502/NarrowNamesTest.jtr > cc'ing i18n-dev as that is where Calendar (and its tests) are maintained. > > The change look okay to me but I wonder if perhaps you have the wrong > bug number. JDK-8019502 is a confused bug but I think it was > originally intended to be an audit of the tests that use Runtime.exec > or ProcessBuilder to see if they should be changed to pass the options > through. I just mention it as I suspect you might need to create a new > bug for this and then split up JDK-8019502 into other tasks. > > -Alan From Alan.Bateman at oracle.com Sat Nov 9 08:46:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 09 Nov 2013 16:46:05 +0000 Subject: RFR for JDK-8019502 some java.util test does not pass VM options when launching java program in script In-Reply-To: <527CB943.8040207@oracle.com> References: <78d57e05-5d19-4766-a3ce-8fdaa2e9106d@default> <527B0D72.703@oracle.com> <527B5856.8090301@oracle.com> <527C5D7F.2000102@oracle.com> <527CADB5.2060702@oracle.com> <527CB943.8040207@oracle.com> Message-ID: <527E66CD.3000408@oracle.com> On 08/11/2013 10:13, Patrick Zhang wrote: > Hi Alan, > > I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to > hold it. > Thanks, I'll push this for you with this new bug number. One thing that would be good to do is to go through all the issues in JDK-8019502 as it doesn't appear that the original issue (related to tests using ProcessBuilder and Runtime.exec) has been addressed by other changes. -Alan. From nashwan.doaqan at gmail.com Thu Nov 14 06:08:49 2013 From: nashwan.doaqan at gmail.com (Nashwan Doaqan) Date: Thu, 14 Nov 2013 17:08:49 +0300 Subject: Add Arabic Language Message-ID: Hi Everyone, I am Nashwan Doaqan a Web Developer from Yemen, I was wondering with some of my friends why the Arabic language is not supported?! I am The Arabic Validator in the WordPress project, and I can help you to translate all the strings in Java UI to the Arabic langauge. Best Regrades Nashwan Doaqan From naoto.sato at oracle.com Thu Nov 14 15:08:32 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 14 Nov 2013 15:08:32 -0800 Subject: Add Arabic Language In-Reply-To: References: Message-ID: <528557F0.4030904@oracle.com> Hi Nashwan, As to whether Java supports Arabic or not, it *does* support Arabic as follows: http://www.oracle.com/technetwork/java/javase/javase7locales-334809.html However, you are right that Arabic translations for those UIs are not included in the run time. Naoto On 13-11-14 ??6:08, Nashwan Doaqan wrote: > Hi Everyone, I am Nashwan Doaqan a Web Developer from Yemen, I was > wondering with some of my friends why the Arabic language is not supported?! > > I am The Arabic Validator in the WordPress project, and I can help you to > translate all the strings in Java UI to the Arabic langauge. > > Best Regrades > Nashwan Doaqan From sean.coffey at oracle.com Fri Nov 15 04:12:54 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 15 Nov 2013 12:12:54 +0000 Subject: RFR: 8027370: (tz) Support tzdata2013h In-Reply-To: <527D1464.3080508@oracle.com> References: <52791F14.2080305@oracle.com> <527D1464.3080508@oracle.com> Message-ID: <52860FC6.70105@oracle.com> Looks good to me too Aleksej. regards, Sean. On 08/11/2013 16:42, Xueming Shen wrote: > looks fine. I would assume you've also run the corresponding tests at > test/closed repo. > > -Sherman > > On 11/5/2013 8:38 AM, Aleksej Efimov wrote: >> Hi, >> >> Can I have a review for tzdata2013h integration [1]. The webrev link >> can be located here [2]. >> >> The following test sets were executed on build with fix: >> test/sun/util/calendar test/java/util/Calendar >> test/sun/util/resources/TimeZone test/sun/util/calendar >> test/java/util/TimeZone test/java/time test/java/util/Formatter >> >> And here is the list of failures: >> FAILED: java/time/tck/java/time/temporal/TCKWeekFields.java %1% >> FAILED: java/time/tck/java/time/TCKInstant.java %1% >> FAILED: java/time/tck/java/time/TCKLocalDate.java %1% >> FAILED: java/time/tck/java/time/TCKLocalDateTime.java %1% >> FAILED: java/time/tck/java/time/TCKOffsetDateTime.java %1% >> FAILED: java/time/tck/java/time/TCKOffsetTime.java %1% >> FAILED: java/time/tck/java/time/TCKZonedDateTime.java %1% >> FAILED: >> java/time/test/java/time/format/TestZoneTextPrinterParser.java %1% >> FAILED: java/util/Calendar/JavatimeTest.java %1% >> >> FAILED: sun/util/calendar/zi/TestZoneInfo310.java >> >> >> The group %1% tests failures relates to the JDK-8027622 bug and are >> expected (actually, it was already resolved in hotspot repo). >> The 'TestZoneInfo310' test failure is an actual error in current >> ZoneInfoFile class implementation in JDK. I have filled a bug for >> this one [3] and will send a separate review with fix later today. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8027370 >> [2] http://cr.openjdk.java.net/~aefimov/8027370/webrev.00/ >> [3] https://bugs.openjdk.java.net/browse/JDK-8027848 > From sean.coffey at oracle.com Fri Nov 15 04:13:19 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 15 Nov 2013 12:13:19 +0000 Subject: 8027848: The ZoneInfoFile doesn't honor future GMT offset changes In-Reply-To: <527A7A01.3010301@oracle.com> References: <52792A58.2050503@oracle.com> <52793E10.1050903@oracle.com> <52793FDC.5010507@oracle.com> <52797D6F.3080209@oracle.com> <527A7A01.3010301@oracle.com> Message-ID: <52860FDF.4040002@oracle.com> Looks good here too Aleksej.. in case you need a second reviewer. regards, Sean. On 06/11/2013 17:18, Xueming Shen wrote: > Looks fine. > > thanks! > -Sherman > > On 11/05/2013 03:21 PM, Aleksej Efimov wrote: >> Sherman, >> Thank you for a quick review. I totally agree with you on all items. >> Actually, I missed fact that the transitions are sorted. And yes - >> the change can be done on line #431. >> The new tested fix can be found here: >> http://cr.openjdk.java.net/~aefimov/8027848/webrev.01/ >> >> >> -Aleksej >> >> On 11/05/2013 10:58 PM, Xueming Shen wrote: >>> On 11/05/2013 10:50 AM, Xueming Shen wrote: >>>> Aleksej, >>>> >>>> For better performance >>>> (1) the currT should be "static final" so we dont have to access the >>>> System.curentTimeMillis() for each TimeZone/ZoneInfo instance. >>>> (2) instead of iterating through the standardTransitions(), >>>> shouldn't we just >>>> check the last one? given it's a sorted list. >>> >>> and maybe this willGMTOffsetChange setting can be done just at >>> line#431. >>> >>> -Sherman >>> >>>> >>>> btw, in theory, the change now uses the "current vm starttime" >>>> instead of >>>> the "tzdb generated" time. But it should be fine, given >>>> ZoneInfo.getRawOffset() >>>> will just do a search for the current rawoffset. I may consider to >>>> add the >>>> "generated time" into the tzdb.dat in the future, if desired. >>>> >>>> Thanks! >>>> -Sherman >>>> >>>> On 11/05/2013 09:26 AM, Aleksej Efimov wrote: >>>>> Hi, >>>>> Can I have a review for a 8027848 [1] bug fix . There is >>>>> unimplemented functionality related to the future GMT offset changes. >>>>> The ZoneInfoFile class doesn't analyses if there is such offset >>>>> changes and as a result incorrectly creates the ZoneInfo instance. >>>>> It was discovered during the TestZoneInfo310 test execution as >>>>> part of tzdata2013h update [3]. >>>>> >>>>> Thanks, >>>>> Aleksej >>>>> >>>>> [1] The bug: https://bugs.openjdk.java.net/browse/JDK-8027848 >>>>> [2] Proposed fix: >>>>> http://cr.openjdk.java.net/~aefimov/8027848/webrev.00 >>>>> [3] tzdata2013h review thread: >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022898.html >>>> >>> >> > From michael.fang at oracle.com Fri Nov 15 09:42:41 2013 From: michael.fang at oracle.com (Michael Fang) Date: Fri, 15 Nov 2013 09:42:41 -0800 Subject: Add Arabic Language In-Reply-To: <528557F0.4030904@oracle.com> References: <528557F0.4030904@oracle.com> Message-ID: <52865D11.4000302@oracle.com> Hi Nashwan, We provided localization instructions around JDK6/7 time at the following URL: http://openjdk.java.net/groups/i18n/ However, there was lack of interest, so we did not continue with the project. The instructions is outdated now. If there is still interest in adding translation for various languages to openjdk, we need come up with updated instruction and process. About the files to translate, I suspect most people are only interested in translating resource files in rt.jar (or a subset of it). Is this what you have in mind? Below is a list of (for example) Spanish files in rt.jar % jar tvf rt.jar | grep _es 5267 Tue Nov 12 00:22:22 PST 2013 com/sun/accessibility/internal/resources/accessibility_es.class 3067 Tue Nov 12 00:22:22 PST 2013 com/sun/java/swing/plaf/gtk/resources/gtk_es.class 2079 Tue Nov 12 00:22:22 PST 2013 com/sun/java/swing/plaf/motif/resources/motif_es.class 2492 Tue Nov 12 00:22:22 PST 2013 com/sun/java/swing/plaf/windows/resources/windows_es.class 39865 Tue Nov 12 00:19:26 PST 2013 com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.class 15393 Tue Nov 12 00:19:24 PST 2013 com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.class 3541 Tue Nov 12 00:19:26 PST 2013 com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.class 2728 Tue Nov 12 00:19:28 PST 2013 com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.class 10387 Tue Nov 12 00:19:20 PST 2013 com/sun/org/apache/xml/internal/res/XMLErrorResources_es.class 4869 Tue Nov 12 00:19:20 PST 2013 com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.class 1319 Tue Nov 12 00:19:22 PST 2013 com/sun/org/apache/xml/internal/utils/res/XResources_es.class 21838 Tue Nov 12 00:19:22 PST 2013 com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.class 9121 Tue Nov 12 00:22:22 PST 2013 com/sun/swing/internal/plaf/basic/resources/basic_es.class 2810 Tue Nov 12 00:22:22 PST 2013 com/sun/swing/internal/plaf/metal/resources/metal_es.class 2350 Tue Nov 12 00:22:22 PST 2013 com/sun/swing/internal/plaf/synth/resources/synth_es.class 16476 Tue Nov 12 00:21:50 PST 2013 sun/applet/resources/MsgAppletViewer_es.class 10391 Tue Nov 12 00:22:24 PST 2013 sun/awt/resources/awt_es.class 7926 Tue Nov 12 00:22:24 PST 2013 sun/launcher/resources/launcher_es.class 5806 Tue Nov 12 00:22:24 PST 2013 sun/management/resources/agent_es.class 934 Tue Nov 12 00:21:56 PST 2013 sun/misc/resources/Messages_es.class 9073 Tue Nov 12 00:22:22 PST 2013 sun/print/resources/serviceui_es.class 25305 Tue Nov 12 00:21:58 PST 2013 sun/security/tools/keytool/Resources_es.class 7661 Tue Nov 12 00:21:58 PST 2013 sun/security/tools/policytool/Resources_es.class 5668 Tue Nov 12 00:21:58 PST 2013 sun/security/util/AuthResources_es.class 7560 Tue Nov 12 00:21:58 PST 2013 sun/security/util/Resources_es.class 3468 Tue Nov 12 00:22:24 PST 2013 sun/tools/jar/resources/jar_es.class 760 Tue Nov 12 00:22:24 PST 2013 sun/util/logging/resources/logging_es.class thanks, -michael On 13?11?14? 03:08 ??, Naoto Sato wrote: > Hi Nashwan, > > As to whether Java supports Arabic or not, it *does* support Arabic as > follows: > > http://www.oracle.com/technetwork/java/javase/javase7locales-334809.html > > However, you are right that Arabic translations for those UIs are not > included in the run time. > > Naoto > > On 13-11-14 ??6:08, Nashwan Doaqan wrote: >> Hi Everyone, I am Nashwan Doaqan a Web Developer from Yemen, I was >> wondering with some of my friends why the Arabic language is not >> supported?! >> >> I am The Arabic Validator in the WordPress project, and I can help >> you to >> translate all the strings in Java UI to the Arabic langauge. >> >> Best Regrades >> Nashwan Doaqan From michael.fang at oracle.com Tue Nov 19 20:33:24 2013 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 19 Nov 2013 20:33:24 -0800 Subject: Add Arabic Language -- or other languages to rt.jar In-Reply-To: References: <528557F0.4030904@oracle.com> <52865D11.4000302@oracle.com> Message-ID: <528C3B94.1050503@oracle.com> Thanks Nashwan. I did not receive reply from other people (ex: developers from RedHat or Ubuntu who might be interested in translating to some languages they support in the Linux distributions), so it's not clear about the interest for other languages. Hopefully we can figure out a common set of files people would like to work on. I would start with just rt.jar (or a subset of it, just the most frequently used properties files) for now when I update the instruction. I need more time to look into the file list. thanks, -michael On 13?11?16? 07:36 ??, Nashwan Doaqan wrote: > Hi Michael, > > An updated list of instructions will be great! .. Actually we plan to > translate *all* the needed strings in JRE and JDK .. but for now we > will start with the resource files in rt.jar > > > On 15 November 2013 20:42, Michael Fang > wrote: > > Hi Nashwan, > > We provided localization instructions around JDK6/7 time at the > following URL: > http://openjdk.java.net/groups/i18n/ > > However, there was lack of interest, so we did not continue with > the project. The instructions is outdated now. If there is still > interest in adding translation for various languages to openjdk, > we need come up with updated instruction and process. > > About the files to translate, I suspect most people are only > interested in translating resource files in rt.jar (or a subset of > it). Is this what you have in mind? Below is a list of (for > example) Spanish files in rt.jar > > % jar tvf rt.jar | grep _es > 5267 Tue Nov 12 00:22:22 PST 2013 > com/sun/accessibility/internal/resources/accessibility_es.class > 3067 Tue Nov 12 00:22:22 PST 2013 > com/sun/java/swing/plaf/gtk/resources/gtk_es.class > 2079 Tue Nov 12 00:22:22 PST 2013 > com/sun/java/swing/plaf/motif/resources/motif_es.class > 2492 Tue Nov 12 00:22:22 PST 2013 > com/sun/java/swing/plaf/windows/resources/windows_es.class > 39865 Tue Nov 12 00:19:26 PST 2013 > com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.class > 15393 Tue Nov 12 00:19:24 PST 2013 > com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.class > 3541 Tue Nov 12 00:19:26 PST 2013 > com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.class > 2728 Tue Nov 12 00:19:28 PST 2013 > com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.class > 10387 Tue Nov 12 00:19:20 PST 2013 > com/sun/org/apache/xml/internal/res/XMLErrorResources_es.class > 4869 Tue Nov 12 00:19:20 PST 2013 > com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.class > 1319 Tue Nov 12 00:19:22 PST 2013 > com/sun/org/apache/xml/internal/utils/res/XResources_es.class > 21838 Tue Nov 12 00:19:22 PST 2013 > com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.class > 9121 Tue Nov 12 00:22:22 PST 2013 > com/sun/swing/internal/plaf/basic/resources/basic_es.class > 2810 Tue Nov 12 00:22:22 PST 2013 > com/sun/swing/internal/plaf/metal/resources/metal_es.class > 2350 Tue Nov 12 00:22:22 PST 2013 > com/sun/swing/internal/plaf/synth/resources/synth_es.class > 16476 Tue Nov 12 00:21:50 PST 2013 > sun/applet/resources/MsgAppletViewer_es.class > 10391 Tue Nov 12 00:22:24 PST 2013 sun/awt/resources/awt_es.class > 7926 Tue Nov 12 00:22:24 PST 2013 > sun/launcher/resources/launcher_es.class > 5806 Tue Nov 12 00:22:24 PST 2013 > sun/management/resources/agent_es.class > 934 Tue Nov 12 00:21:56 PST 2013 > sun/misc/resources/Messages_es.class > 9073 Tue Nov 12 00:22:22 PST 2013 > sun/print/resources/serviceui_es.class > 25305 Tue Nov 12 00:21:58 PST 2013 > sun/security/tools/keytool/Resources_es.class > 7661 Tue Nov 12 00:21:58 PST 2013 > sun/security/tools/policytool/Resources_es.class > 5668 Tue Nov 12 00:21:58 PST 2013 > sun/security/util/AuthResources_es.class > 7560 Tue Nov 12 00:21:58 PST 2013 > sun/security/util/Resources_es.class > 3468 Tue Nov 12 00:22:24 PST 2013 > sun/tools/jar/resources/jar_es.class > 760 Tue Nov 12 00:22:24 PST 2013 > sun/util/logging/resources/logging_es.class > > thanks, > > -michael > > > On 13?11?14? 03:08 ??, Naoto Sato wrote: > > Hi Nashwan, > > As to whether Java supports Arabic or not, it *does* support > Arabic as follows: > > http://www.oracle.com/technetwork/java/javase/javase7locales-334809.html > > However, you are right that Arabic translations for those UIs > are not included in the run time. > > Naoto > > On 13-11-14 ??6:08, Nashwan Doaqan wrote: > > Hi Everyone, I am Nashwan Doaqan a Web Developer from > Yemen, I was > wondering with some of my friends why the Arabic language > is not supported?! > > I am The Arabic Validator in the WordPress project, and I > can help you to > translate all the strings in Java UI to the Arabic langauge. > > Best Regrades > Nashwan Doaqan > > > From Alan.Bateman at oracle.com Wed Nov 20 09:08:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Nov 2013 17:08:46 +0000 Subject: 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone Message-ID: <528CEC9E.4030308@oracle.com> We have a number of test failures in agentvm mode that appear to be caused by tests changing the default TimeZone and not restoring it. These failures become very intermittently when running with concurrency as it is unpredictable as to the sequence of tests that a specific agent VM will execute from run to run. As part of tracking down these issues, I hacked on jtreg to error tests that complete with a different TimeZone that they were run with. This lead me to InternationalBAT.java which sets the TimeZone to GMT but doesn't restore it. I'd like to fix this test to restore the time zone, the proposed patch is attached. Thanks, -Alan. diff --git a/test/java/util/Locale/InternationalBAT.java b/test/java/util/Locale/InternationalBAT.java --- a/test/java/util/Locale/InternationalBAT.java +++ b/test/java/util/Locale/InternationalBAT.java @@ -39,11 +39,13 @@ public static void main(String[] args) { boolean pass = true; - if (!testRequiredLocales()) { - pass = false; - } - if (!testRequiredEncodings()) { - pass = false; + + TimeZone tz = TimeZone.getDefault(); + try { + pass &= testRequiredLocales(); + pass &= testRequiredEncodings(); + } finally { + TimeZone.setDefault(tz); } if (!pass) { From naoto.sato at oracle.com Wed Nov 20 09:32:41 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 20 Nov 2013 09:32:41 -0800 Subject: 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone In-Reply-To: <528CEC9E.4030308@oracle.com> References: <528CEC9E.4030308@oracle.com> Message-ID: <528CF239.3090306@oracle.com> Looks good to me. Naoto On 13-11-20 ??9:08, Alan Bateman wrote: > > We have a number of test failures in agentvm mode that appear to be > caused by tests changing the default TimeZone and not restoring it. > These failures become very intermittently when running with concurrency > as it is unpredictable as to the sequence of tests that a specific agent > VM will execute from run to run. > > As part of tracking down these issues, I hacked on jtreg to error tests > that complete with a different TimeZone that they were run with. This > lead me to InternationalBAT.java which sets the TimeZone to GMT but > doesn't restore it. > > I'd like to fix this test to restore the time zone, the proposed patch > is attached. > > Thanks, > > -Alan. > > > diff --git a/test/java/util/Locale/InternationalBAT.java > b/test/java/util/Locale/InternationalBAT.java > --- a/test/java/util/Locale/InternationalBAT.java > +++ b/test/java/util/Locale/InternationalBAT.java > @@ -39,11 +39,13 @@ > > public static void main(String[] args) { > boolean pass = true; > - if (!testRequiredLocales()) { > - pass = false; > - } > - if (!testRequiredEncodings()) { > - pass = false; > + > + TimeZone tz = TimeZone.getDefault(); > + try { > + pass &= testRequiredLocales(); > + pass &= testRequiredEncodings(); > + } finally { > + TimeZone.setDefault(tz); > } > > if (!pass) { From masayoshi.okutsu at oracle.com Thu Nov 21 01:33:19 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 21 Nov 2013 18:33:19 +0900 Subject: 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone In-Reply-To: <528CEC9E.4030308@oracle.com> References: <528CEC9E.4030308@oracle.com> Message-ID: <528DD35F.7070703@oracle.com> On 11/21/2013 2:08 AM, Alan Bateman wrote: > We have a number of test failures in agentvm mode that appear to be > caused by tests changing the default TimeZone and not restoring it. > These failures become very intermittently when running with > concurrency as it is unpredictable as to the sequence of tests that a > specific agent VM will execute from run to run. If concurrent execution is a requirement, all tests changing default time zone and/or locale values need to run in "othervm"? Masayoshi From Alan.Bateman at oracle.com Thu Nov 21 01:40:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Nov 2013 09:40:08 +0000 Subject: 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone In-Reply-To: <528DD35F.7070703@oracle.com> References: <528CEC9E.4030308@oracle.com> <528DD35F.7070703@oracle.com> Message-ID: <528DD4F8.6040107@oracle.com> On 21/11/2013 09:33, Masayoshi Okutsu wrote: > On 11/21/2013 2:08 AM, Alan Bateman wrote: >> We have a number of test failures in agentvm mode that appear to be >> caused by tests changing the default TimeZone and not restoring it. >> These failures become very intermittently when running with >> concurrency as it is unpredictable as to the sequence of tests that a >> specific agent VM will execute from run to run. > > If concurrent execution is a requirement, all tests changing default > time zone and/or locale values need to run in "othervm"? When you run in agentvm mode with concurrency then it means there is a pool of agent VMs running the tests, it doesn't mean there are several tests running in the same agent VM at the same time. So if tests change the default TZ or locale or other global settings then the tests need to restore them so as to not cause problems for tests that run subsequently. If they can't restore things (and we have many examples of that) then you are right, these tests needs to have their @run tag changed so that they always run in othervm mode. -Alan From masayoshi.okutsu at oracle.com Thu Nov 21 01:43:29 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 21 Nov 2013 18:43:29 +0900 Subject: 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone In-Reply-To: <528DD4F8.6040107@oracle.com> References: <528CEC9E.4030308@oracle.com> <528DD35F.7070703@oracle.com> <528DD4F8.6040107@oracle.com> Message-ID: <528DD5C1.70005@oracle.com> I see. Thanks! Masayoshi On 11/21/2013 6:40 PM, Alan Bateman wrote: > On 21/11/2013 09:33, Masayoshi Okutsu wrote: >> On 11/21/2013 2:08 AM, Alan Bateman wrote: >>> We have a number of test failures in agentvm mode that appear to be >>> caused by tests changing the default TimeZone and not restoring it. >>> These failures become very intermittently when running with >>> concurrency as it is unpredictable as to the sequence of tests that >>> a specific agent VM will execute from run to run. >> >> If concurrent execution is a requirement, all tests changing default >> time zone and/or locale values need to run in "othervm"? > When you run in agentvm mode with concurrency then it means there is a > pool of agent VMs running the tests, it doesn't mean there are several > tests running in the same agent VM at the same time. > > So if tests change the default TZ or locale or other global settings > then the tests need to restore them so as to not cause problems for > tests that run subsequently. If they can't restore things (and we have > many examples of that) then you are right, these tests needs to have > their @run tag changed so that they always run in othervm mode. > > -Alan From michael.fang at oracle.com Thu Nov 21 15:12:27 2013 From: michael.fang at oracle.com (Michael Fang) Date: Thu, 21 Nov 2013 15:12:27 -0800 Subject: [8] Request for review: 8028803: jdk8 l10n resource file translation update 5 - jaxp repo Message-ID: <528E935B.8090303@oracle.com> Hi, Please help to review the changes for the following CR: https://bugs.openjdk.java.net/browse/JDK-8028803 A list of English resource files are sent to translation vendors for translation update periodically that's why these l10n resource files have been updated. You do not need to review the translation content. We just need to make sure there are no technical issues. Follow up i18n/l10n testing will be performed in promotion builds and i18n/l10n bugs will be reported and addressed. The webrev is available here: http://cr.openjdk.java.net/~mfang/8028803/ thanks, -michael From huizhe.wang at oracle.com Thu Nov 21 15:41:42 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 21 Nov 2013 15:41:42 -0800 Subject: [8] Request for review: 8028803: jdk8 l10n resource file translation update 5 - jaxp repo In-Reply-To: <528E935B.8090303@oracle.com> References: <528E935B.8090303@oracle.com> Message-ID: <528E9A36.6090505@oracle.com> Hi Michael, Looks good. I see that the new messages are in XMLMessages*. Others are minor fixes for some language files, such as _it or _zh, I can't read them any ways :-) I trust the translation team for that. Thanks, Joe On 11/21/2013 3:12 PM, Michael Fang wrote: > Hi, > > Please help to review the changes for the following CR: > https://bugs.openjdk.java.net/browse/JDK-8028803 > > A list of English resource files are sent to translation vendors for > translation update periodically that's why these l10n resource files > have been updated. > > You do not need to review the translation content. We just need to > make sure there are no technical issues. Follow up i18n/l10n testing > will be performed in promotion builds and i18n/l10n bugs will be > reported and addressed. > > The webrev is available here: > http://cr.openjdk.java.net/~mfang/8028803/ > > thanks, > > -michael From michael.fang at oracle.com Thu Nov 21 15:42:32 2013 From: michael.fang at oracle.com (Michael Fang) Date: Thu, 21 Nov 2013 15:42:32 -0800 Subject: [8] Request for review: 8028803: jdk8 l10n resource file translation update 5 - jaxp repo In-Reply-To: <528E9A36.6090505@oracle.com> References: <528E935B.8090303@oracle.com> <528E9A36.6090505@oracle.com> Message-ID: <528E9A68.5030104@oracle.com> Thanks Joe for the review. -michael On 13?11?21? 03:41 ??, huizhe wang wrote: > Hi Michael, > > Looks good. I see that the new messages are in XMLMessages*. Others > are minor fixes for some language files, such as _it or _zh, I can't > read them any ways :-) I trust the translation team for that. > > Thanks, > Joe > > On 11/21/2013 3:12 PM, Michael Fang wrote: >> Hi, >> >> Please help to review the changes for the following CR: >> https://bugs.openjdk.java.net/browse/JDK-8028803 >> >> A list of English resource files are sent to translation vendors for >> translation update periodically that's why these l10n resource files >> have been updated. >> >> You do not need to review the translation content. We just need to >> make sure there are no technical issues. Follow up i18n/l10n testing >> will be performed in promotion builds and i18n/l10n bugs will be >> reported and addressed. >> >> The webrev is available here: >> http://cr.openjdk.java.net/~mfang/8028803/ >> >> thanks, >> >> -michael > From naoto.sato at oracle.com Mon Nov 25 10:49:11 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 25 Nov 2013 10:49:11 -0800 Subject: [8] RFR: JDK-8028368 : There is no description whether or not java.util.ResourceBundle is thread-safe Message-ID: <52939BA7.4080402@oracle.com> Hello, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8028368 The proposed changeset is here: http://cr.openjdk.java.net/~naoto/8028368/webrev.00/ It is just a clarification of the current behavior in the spec. Naoto From yuka.kamiya at oracle.com Mon Nov 25 21:27:40 2013 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Tue, 26 Nov 2013 14:27:40 +0900 Subject: [8] RFR: JDK-8029057 : test/java/text/Bidi/Bug6665028.java can fail with OutOfMemoryError Message-ID: <5294314C.50206@oracle.com> Hello, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8029057 test/java/text/Bidi/Bug6665028.java can fail with OutOfMemoryError Fix: http://cr.openjdk.java.net/~peytoia/8029057/webrev.00/ The test program was for an old implementation which no longer exists. We decided to remove it. Thanks, -- Yuka From masayoshi.okutsu at oracle.com Mon Nov 25 21:41:08 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 26 Nov 2013 14:41:08 +0900 Subject: [8] RFR: JDK-8029057 : test/java/text/Bidi/Bug6665028.java can fail with OutOfMemoryError In-Reply-To: <5294314C.50206@oracle.com> References: <5294314C.50206@oracle.com> Message-ID: <52943474.30909@oracle.com> Looks good. Masayoshi On 11/26/2013 2:27 PM, Yuka Kamiya wrote: > Hello, > > Please review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8029057 > test/java/text/Bidi/Bug6665028.java can fail with OutOfMemoryError > > Fix: > http://cr.openjdk.java.net/~peytoia/8029057/webrev.00/ > > The test program was for an old implementation which no longer exists. > We decided to remove it. > > Thanks, > -- > Yuka > From naoto.sato at oracle.com Tue Nov 26 11:16:05 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 26 Nov 2013 11:16:05 -0800 Subject: [8] RFR: 8028771: regression test java/util/Locale/LocaleProviders.sh failed Message-ID: <5294F375.1000003@oracle.com> Hello, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8028771 Here is the proposed fix: http://cr.openjdk.java.net/~naoto/8028771/webrev.00/ The test case needs to be modified to check whether the expected locale provider adapter indeed supports the requested locale. This check needs to be performed at runtime in case of HOST adapter in which the supported locales vary depending on user's settings. Naoto From michael.fang at oracle.com Tue Nov 26 16:00:31 2013 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 26 Nov 2013 16:00:31 -0800 Subject: [8] Request for review: 8027244: Need to translate new error message and usage information for jar tool Message-ID: <5295361F.7050905@oracle.com> Hi, Please help to review the changes for the following CR: https://bugs.openjdk.java.net/browse/JDK-8027244 The webrev is available here: http://cr.openjdk.java.net/~mfang/8027244/ Only 2 lines were changed in each file which corresponded to the changes in English jar.properties file: http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/3cdf6ca3ef47/src/share/classes/sun/tools/jar/resources/jar.properties thanks, -michael From michael.fang at oracle.com Tue Nov 26 16:18:26 2013 From: michael.fang at oracle.com (Michael Fang) Date: Tue, 26 Nov 2013 16:18:26 -0800 Subject: [8] Request for review: 8026741: jdk8 l10n resource file translation update 5 Message-ID: <52953A52.6040704@oracle.com> Hi, Please help to review the changes for the following CR: https://bugs.openjdk.java.net/browse/JDK-8026741 A list of English resource files were sent to translation vendors for translation update periodically that's why these l10n resource files have been updated. You do not need to review the translation content. We just need to make sure there are no technical issues. Follow up i18n/l10n testing will be performed in promotion builds and i18n/l10n bugs will be reported and addressed. The webrev is available here: http://cr.openjdk.java.net/~mfang/8026741/ thanks, -michael From naoto.sato at oracle.com Wed Nov 27 08:19:54 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 27 Nov 2013 08:19:54 -0800 Subject: [8] RFR: 8028771: regression test java/util/Locale/LocaleProviders.sh failed In-Reply-To: <5294F375.1000003@oracle.com> References: <5294F375.1000003@oracle.com> Message-ID: <52961BAA.7040208@oracle.com> Ping. I need to push this by 12/04, so your help is needed. Naoto On 13-11-26 ??11:16, Naoto Sato wrote: > Hello, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8028771 > > Here is the proposed fix: > > http://cr.openjdk.java.net/~naoto/8028771/webrev.00/ > > The test case needs to be modified to check whether the expected locale > provider adapter indeed supports the requested locale. This check needs > to be performed at runtime in case of HOST adapter in which the > supported locales vary depending on user's settings. > > Naoto From naoto.sato at oracle.com Wed Nov 27 08:20:26 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 27 Nov 2013 08:20:26 -0800 Subject: [8] RFR: JDK-8028368 : There is no description whether or not java.util.ResourceBundle is thread-safe In-Reply-To: <52939BA7.4080402@oracle.com> References: <52939BA7.4080402@oracle.com> Message-ID: <52961BCA.2080303@oracle.com> And this one too. Thanks! Naoto On 13-11-25 ??10:49, Naoto Sato wrote: > Hello, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8028368 > > The proposed changeset is here: > > http://cr.openjdk.java.net/~naoto/8028368/webrev.00/ > > It is just a clarification of the current behavior in the spec. > > Naoto From Alan.Bateman at oracle.com Wed Nov 27 08:45:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Nov 2013 16:45:31 +0000 Subject: [8] RFR: 8028771: regression test java/util/Locale/LocaleProviders.sh failed In-Reply-To: <52961BAA.7040208@oracle.com> References: <5294F375.1000003@oracle.com> <52961BAA.7040208@oracle.com> Message-ID: <529621AB.4050705@oracle.com> On 27/11/2013 16:19, Naoto Sato wrote: > Ping. I need to push this by 12/04, so your help is needed. > > Naoto If I understand correctly then it just means the tests silently passes when run on systems that are configured in a manner that requires a calendar that the JDK doesn't support. In that case, the change looks okay to me. -Alan From naoto.sato at oracle.com Wed Nov 27 09:06:17 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 27 Nov 2013 09:06:17 -0800 Subject: [8] RFR: 8028771: regression test java/util/Locale/LocaleProviders.sh failed In-Reply-To: <529621AB.4050705@oracle.com> References: <5294F375.1000003@oracle.com> <52961BAA.7040208@oracle.com> <529621AB.4050705@oracle.com> Message-ID: <52962689.7060902@oracle.com> Thanks, Alan. That's exactly what the fix is intended for. Naoto On 13-11-27 ??8:45, Alan Bateman wrote: > On 27/11/2013 16:19, Naoto Sato wrote: >> Ping. I need to push this by 12/04, so your help is needed. >> >> Naoto > If I understand correctly then it just means the tests silently passes > when run on systems that are configured in a manner that requires a > calendar that the JDK doesn't support. In that case, the change looks > okay to me. > > -Alan From naoto.sato at oracle.com Wed Nov 27 10:04:11 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 27 Nov 2013 10:04:11 -0800 Subject: [8] Request for review: 8027244: Need to translate new error message and usage information for jar tool In-Reply-To: <5295361F.7050905@oracle.com> References: <5295361F.7050905@oracle.com> Message-ID: <5296341B.4050707@oracle.com> Looks good to me. Naoto On 13-11-26 ??4:00, Michael Fang wrote: > Hi, > > Please help to review the changes for the following CR: > https://bugs.openjdk.java.net/browse/JDK-8027244 > > The webrev is available here: > http://cr.openjdk.java.net/~mfang/8027244/ > > Only 2 lines were changed in each file which corresponded to the changes > in English jar.properties file: > http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/3cdf6ca3ef47/src/share/classes/sun/tools/jar/resources/jar.properties > > > thanks, > > -michael From michael.fang at oracle.com Wed Nov 27 10:16:16 2013 From: michael.fang at oracle.com (Michael Fang) Date: Wed, 27 Nov 2013 10:16:16 -0800 Subject: [8] Request for review: 8027244: Need to translate new error message and usage information for jar tool In-Reply-To: <5296341B.4050707@oracle.com> References: <5295361F.7050905@oracle.com> <5296341B.4050707@oracle.com> Message-ID: <529636F0.6050907@oracle.com> Thank you Naoto for the review! -michael On 13?11?27? 10:04 ??, Naoto Sato wrote: > Looks good to me. > > Naoto > > On 13-11-26 ??4:00, Michael Fang wrote: >> Hi, >> >> Please help to review the changes for the following CR: >> https://bugs.openjdk.java.net/browse/JDK-8027244 >> >> The webrev is available here: >> http://cr.openjdk.java.net/~mfang/8027244/ >> >> Only 2 lines were changed in each file which corresponded to the changes >> in English jar.properties file: >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/3cdf6ca3ef47/src/share/classes/sun/tools/jar/resources/jar.properties >> >> >> >> thanks, >> >> -michael From masayoshi.okutsu at oracle.com Thu Nov 28 00:47:23 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 28 Nov 2013 17:47:23 +0900 Subject: [8] RFR: JDK-8028368 : There is no description whether or not java.util.ResourceBundle is thread-safe In-Reply-To: <52961BCA.2080303@oracle.com> References: <52939BA7.4080402@oracle.com> <52961BCA.2080303@oracle.com> Message-ID: <5297031B.2000408@oracle.com> Hi Naoto, I'd like to wait until the API change proposal gets approved. Thanks, Masayoshi On 11/28/2013 1:20 AM, Naoto Sato wrote: > And this one too. Thanks! > > Naoto > > On 13-11-25 ??10:49, Naoto Sato wrote: >> Hello, >> >> Please review the fix for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8028368 >> >> The proposed changeset is here: >> >> http://cr.openjdk.java.net/~naoto/8028368/webrev.00/ >> >> It is just a clarification of the current behavior in the spec. >> >> Naoto