Hi Muneer,
Thank you for the update!
See inline:
On Tue, Jun 11, 2019 at 11:35 AM <[email protected]
<mailto:[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
*
o 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.
*
o
* https://bugs.openjdk.java.net/browse/JDK-8225245
o Regression in b21
See below.
*
o
* https://bugs.openjdk.java.net/browse/JDK-8225247
o 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
*
o
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] <mailto:[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]
<mailto:[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]>
<mailto:[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>
<tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961> <tel:+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
