Hi Muneer, Thank you for the update!
See inline: On Tue, Jun 11, 2019 at 11:35 AM <[email protected]> wrote: > Hi Martin, > > The bugs have been updated and closed as Not an Issue. > > Please see the explanations below. > > -Muneer > > On 04/06/19 8:44 PM, Rory O'Donnell wrote: > > Hi Martin, > > The Java Incidents have been reviewed and moved to the Java Bug system > (JBS). > > - https://bugs.openjdk.java.net/browse/JDK-8225240 > > > - > - Regression in b21 > > The definition of the CLDR's "year" pattern is: > --- > Calendar year (numeric). In most cases the length of the y field specifies > the minimum number of digits to display, zero-padded as necessary; more > digits will be displayed if needed to show the full year. However, “yy” > requests just the two low-order digits of the year, zero-padded as > necessary. > --- > > This is consistent with SimpleDateFormat's year pattern. Since b21, CLDR > in the JDK has been upgraded to v35.1 (JDK-8221432), and thus the 4 digit > year is displayed. > > > - > - > - https://bugs.openjdk.java.net/browse/JDK-8225245 > - Regression in b21 > > See below. > > > - > - > - https://bugs.openjdk.java.net/browse/JDK-8225247 > - Regression in b21 > > CLDR has changed the grouping separator for French in v34, from U+00A0 to > U+202F: > https://www.unicode.org/cldr/charts/34/delta/fr.html#Symbols > JDK has been based on v35.1 since b21 (JDK-8221432), thus the applications > that expect the French grouping separator to be U+00A0 will not work. > > Instead of hardcoding \u00A0, applications can use > DecimalFormatSymbols.getInstance(Locale.FRENCH).getGroupingSeparator(). > That makes sense! But I am having trouble making the following test pass with latest Java 13: import static java.lang.String.format; import java.text.DecimalFormat; import java.text.DecimalFormatSymbols; import java.text.NumberFormat; import java.util.Locale; public class Java13Regression2 { public static void main(String[] args) { final Locale locale = Locale.FRENCH; final NumberFormat numberFormat = NumberFormat.getCurrencyInstance(locale); ((DecimalFormat) numberFormat).setParseBigDecimal(true); final DecimalFormatSymbols decimalFormatSymbols = DecimalFormatSymbols.getInstance(locale); char groupingSeparator = decimalFormatSymbols.getGroupingSeparator(); String currencySymbol = decimalFormatSymbols.getCurrencySymbol(); String expected = format("1%s234,00%s%s", groupingSeparator, groupingSeparator, currencySymbol); // <<<<< HERE final String formatted = numberFormat.format(1234f); formatted.codePoints().forEach(System.err::println); // prints true for Java 13 build 18 and earlier (Java 12, 11, ...) // But prints false for Java 13 build 23 System.out.println(expected.equals(formatted)); } } With latest Java 13 the second groupingSeparator again is something else that is none of the available separators in DecimalFormatSymbols. The test passes with earlier versions of Java. Regards, Martin > > - > - > > Thanks again, Rory > On 04/06/2019 09:38, Rory O'Donnell wrote: > > Thanks Martin! > On 04/06/2019 09:22, Martin Grigorov wrote: > > Hi Rory, > > The reports are: > > 9061053 > 9061054 > 9061055 > > Regards, > Martin > > On Tue, Jun 4, 2019 at 10:46 AM Rory O'Donnell <[email protected]> > wrote: > >> Hi Martin, >> >> Can you please log the bug via [1], let me know the JI-Number and we will >> monitor the progress. >> >> Rgds,Rory >> >> [1] http://bugs.java.com/ >> >> On 03/06/2019 18:41, Martin Grigorov wrote: >> >> Hi Dalibor, >> >> I do not see a "Register" link at >> https://bugs.openjdk.java.net/secure/Dashboard.jspa. Is this the correct >> JIRA to report the problem ? >> >> Here is the code snippet that reproduces the problem: >> >> public class Java13Regression1 >> { >> public static void main(String[] args) >> { >> NumberFormat numberFormat = NumberFormat.getInstance(Locale.FRENCH); >> ((DecimalFormat) numberFormat).setParseBigDecimal(true); >> final ParsePosition position = new ParsePosition(0); >> >> // Convert spaces to no-break space (U+00A0) as required by Java >> formats: >> // http://bugs.sun.com/view_bug.do?bug_id=4510618 >> String value = "3 000".replaceAll("(\\d+)\\s(?=\\d)", "$1\u00A0"); >> // this causes the problem >> >> numberFormat.parseObject(value, position); >> >> // prints 5 for Java 13 build 18 and earlier (Java 12, 11, ...) >> // But prints 1 for Java 13 build 23 >> System.err.println("Position index: " + position.getIndex()); >> } >> >> } >> >> Regards, >> Martin >> >> On Mon, Jun 3, 2019 at 3:38 PM Dalibor Topic <[email protected]> >> wrote: >> >>> Hi, >>> >>> this might be a side effect of the update to CLDR 35.1. >>> >>> I don't see anything related in JBS about currency or decimal formatting >>> issues introduced in JDK 13, so I think a bug report would be great. >>> >>> cheers, >>> dalibor topic >>> >>> On 01.06.2019 17:28, Martin Grigorov wrote: >>> > Hi Rory, >>> > >>> > There are several test failures in Wicket due to some change in the >>> > Decimal and Currency formatting/pasrsing: >>> > >>> > cat >>> > >>> wicket-util/target/surefire-reports/org.apache.wicket.util.convert.converters.ConvertersTest.txt >>> >>> > >>> > master … 2 ⚑ 9 >>> > >>> ───────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── >>> > │ File: >>> > >>> target/surefire-reports/org.apache.wicket.util.convert.converters.ConvertersTest.txt >>> > >>> ───────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── >>> > 1 │ >>> > >>> ------------------------------------------------------------------------------- >>> > 2 │ Test set: >>> org.apache.wicket.util.convert.converters.ConvertersTest >>> > 3 │ >>> > >>> ------------------------------------------------------------------------------- >>> > 4 │ Tests run: 42, Failures: 3, Errors: 1, Skipped: 0, Time >>> > elapsed: 0.076 s <<< FAILURE! - in >>> > org.apache.wicket.util.convert.converters.ConvertersTest >>> > 5 │ thousandSeperatorWithCurrency Time elapsed: 0.011 s <<< >>> FAILURE! >>> > 6 │ org.opentest4j.AssertionFailedError: expected: <1 234,00 ¤> >>> > but was: <1 234,00 ¤> >>> > 7 │ at >>> > >>> org.apache.wicket.util.convert.converters.ConvertersTest.thousandSeperatorWithCurrency(ConvertersTest.java:84) >>> > 8 │ >>> > 9 │ thousandSeperator Time elapsed: 0.002 s <<< ERROR! >>> > 10 │ org.apache.wicket.util.convert.ConversionException: Cannot >>> > parse '3 000' using format java.text.DecimalFormat@674dc >>> > 11 │ at >>> > >>> org.apache.wicket.util.convert.converters.ConvertersTest.thousandSeperator(ConvertersTest.java:57) >>> > 12 │ >>> > 13 │ calendarConverter Time elapsed: 0.017 s <<< FAILURE! >>> > 14 │ org.opentest4j.AssertionFailedError: expected: <01-05-11> >>> but >>> > was: <01-05-2011> >>> > 15 │ at >>> > >>> org.apache.wicket.util.convert.converters.ConvertersTest.calendarConverter(ConvertersTest.java:434) >>> > 16 │ >>> > 17 │ validDateConverters Time elapsed: 0.001 s <<< FAILURE! >>> > 18 │ org.opentest4j.AssertionFailedError: expected: <24-10-02> >>> but >>> > was: <24-10-2002> >>> > 19 │ at >>> > >>> org.apache.wicket.util.convert.converters.ConvertersTest.validDateConverters(ConvertersTest.java:400) >>> > >>> > This test was fine with the previous build of 13 and is also OK with >>> > Java 11 and 12. >>> > Please let me know if this is not reported yet and I will try to >>> prepare >>> > plain Java test (without Wicket) that reproduces the issue! >>> > >>> > Regards, >>> > Martin >>> > >>> > On Fri, May 31, 2019 at 10:25 AM Rory O'Donnell >>> > <[email protected] <mailto:[email protected]>> wrote: >>> > >>> > Hi Martin, >>> > >>> > >>> > *OpenJDK builds *- JDK 13 - Early Access build 23 is >>> available at >>> > http://jdk.java.net/13/ >>> > >>> > * These early-access , open-source builds are provided under the >>> > o GNU General Public License, version 2, with the Classpath >>> > Exception <http://openjdk.java.net/legal/gplv2+ce.html>. >>> > * Changes in this build >>> > >>> > < >>> http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B22%22%3A%3A%22jdk-13%2B23%22-%22jdk-13%2B22%22%29&revcount=1000 >>> > >>> > >>> > * Release notes [1] >>> > >>> > >>> > *Significant changes since the last availability email* >>> > >>> > * build 23 >>> > o Support for Unicode 12.1 (JDK-8221431 >>> > <https://bugs.openjdk.java.net/browse/JDK-8221431>) >>> > o Add new keytool -showinfo -tls command for displaying TLS >>> > configuration information (JDK-8219861 >>> > <https://bugs.openjdk.java.net/browse/JDK-8219861>) >>> > * build 22 >>> > o New methods for creating DOM and SAX factories with >>> Namespace >>> > support (JDK-8219692 >>> > <https://bugs.openjdk.java.net/browse/JDK-8219692>) >>> > o Removal of two DocuSign root CA certificates (JDK-8223499 >>> > <https://bugs.openjdk.java.net/browse/JDK-8223499>) >>> > * build 21 >>> > o JDWP support for IPv6 (JDK-8184770 >>> > <https://bugs.openjdk.java.net/browse/JDK-8184770>) >>> > o Change the mechanism by which JDK loads the >>> platform-specific >>> > AWT Toolkit (JDK-8212700 >>> > <https://bugs.openjdk.java.net/browse/JDK-8212700>) >>> > o Upgrade CLDR to Version 35.1 (JDK-8221432 >>> > <https://bugs.openjdk.java.net/browse/JDK-8221432>) >>> > o xConfigurable Read Timeout for CRLs (JDK-8191808 >>> > <https://bugs.openjdk.java.net/browse/JDK-8191808>) >>> > o Removal of two Comodo root CA certificates (JDK-8222136 >>> > <https://bugs.openjdk.java.net/browse/JDK-8222136>) >>> > >>> > >>> > Bug fixes for issues reported by Open Source Projects >>> > >>> > * build 22 >>> > o OutOfMemory on compiling with darcula.jar in classpath >>> > (JDK-8222807 >>> > <https://bugs.openjdk.java.net/browse/JDK-8222807>) >>> > * build 21 >>> > o java -version output and certain system properties contain >>> > "null" text in their values (JDK-8223695 >>> > <https://bugs.openjdk.java.net/browse/JDK-8223695>) >>> > * build 20 >>> > o assert(Compile::current()->live_nodes() < >>> > Compile::current()->max_node_limit()) failed: Live Node >>> limit >>> > exceeded limit (JDK-8219520 >>> > <https://bugs.openjdk.java.net/browse/JDK-8219520>) >>> > o C2: MemNode::can_see_stored_value() ignores casts which >>> carry >>> > control dependency (JDK-8219902 >>> > <https://bugs.openjdk.java.net/browse/JDK-8219902>) >>> > o New fix of the deadlock in sun.security.ssl.SSLSocketImpl >>> > (JDK-8219991 >>> > <https://bugs.openjdk.java.net/browse/JDK-8219991>) >>> > >>> > >>> > JEP updates since last email >>> > >>> > * JEP 350: Dynamic CDS Archives >>> > <http://openjdk.java.net/jeps/350> was >>> > *Integrated*. >>> > * JEP 351: ZGC: Uncommit Unused Memory >>> > <http://openjdk.java.net/jeps/351> was *Integrated*. >>> > * JEP 353: Reimplement the Legacy Socket API >>> > <http://openjdk.java.net/jeps/353> was*Targetted* JDK 13. >>> > * JEP 355: Text Blocks (Preview) >>> > <http://openjdk.java.net/jeps/355> was *Proposed to >>> target* JDK 13. >>> > >>> > >>> > Rgds,Rory >>> > >>> > [1] http://jdk.java.net/13/release-notes >>> > >>> > -- >>> > Rgds, Rory O'Donnell >>> > Quality Engineering Manager >>> > Oracle EMEA, Dublin, Ireland >>> > >>> >>> -- >>> Oracle <http://www.oracle.com> >>> Dalibor Topic | Principal Product Manager >>> Phone: +494089091214 <tel:+494089091214> <+494089091214> | Mobile: >>> +491737185961 >>> <tel:+491737185961> <+491737185961> >>> >>> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | D-22761 Hamburg >>> >>> ORACLE Deutschland B.V. & Co. KG >>> Hauptverwaltung: Riesstr. 25, D-80992 München >>> Registergericht: Amtsgericht München, HRA 95603 >>> >>> Komplementärin: ORACLE Deutschland Verwaltung B.V. >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >>> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 >>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher >>> >>> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to >>> developing practices and products that help protect the environment >>> >> -- >> Rgds, Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA, Dublin, Ireland >> >> -- > Rgds, Rory O'Donnell > Quality Engineering Manager > Oracle EMEA, Dublin, Ireland > > -- > Rgds, Rory O'Donnell > Quality Engineering Manager > Oracle EMEA, Dublin, Ireland > > >
