Thank you, Muneer! I've adapted Wicket's tests to the new rules!
Regards, Martin On Thu, Jun 13, 2019 at 9:24 AM <[email protected]> wrote: > Hi Martin, > > This bug is also closed as Not an Issue with the below comment: > > "The sample is incorrectly expecting that the space between the number and > the currency symbol is the same as the grouping separator. It's not a > grouping separator but a NBSP." > > -Muneer > > On 12/06/19 3:48 PM, [email protected] wrote: > > Hi Martin, > > I raised this as a new bug and JDK id is > https://bugs.openjdk.java.net/browse/JDK-8225650 > > -Muneer > > On 11/06/19 4:21 PM, Martin Grigorov wrote: > > 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 >> >> >> > >
