[
https://issues.apache.org/jira/browse/SOLR-13580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874358#comment-16874358
]
Hoss Man commented on SOLR-13580:
---------------------------------
[https://bugs.openjdk.java.net/browse/JDK-8226867]
{quote}
JDK-13 uses the CLDR v35 . From CLDR v34, the French grouping separator changed
from no-break space U+00A0 to narrow no-break space U+202F. (Reference Release
Notes for CLDR v34 : http://cldr.unicode.org/index/downloads/cldr-34 )
"10\u202F0898,83491" will give the expected result :
### input = 10?0898,83491
100898.83491
class java.lang.Double
java.text.ParsePosition[index=13,errorIndex=-1]
{quote}
Linked issue: https://bugs.openjdk.java.net/browse/JDK-8225245
{quote}
Instead of hardcoding \u00A0, applications can use
DecimalFormatSymbols.getInstance(Locale.FRENCH).getGroupingSeparator().
{quote}
...so it looks like we can change the test to work regardless of java version
by using DecimalFormatSymbols to determine the corect grouping character at
runtime -- but that won't change the fact that end users who don't know any
better might see a back compat break (in the ParseNumeric UpdateProcessors) if
they upgrade to java13 ... so we should mak sure the isue description spells
this out.
not sure there is much we can safely do to mitigate this for users across all
possible locales that my be affected.
> java 13-ea NumberFormat.parse bugs in some Locales, affects ParseNumeric
> UpdateProcessors when using the 'locale' config option
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-13580
> URL: https://issues.apache.org/jira/browse/SOLR-13580
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Major
> Labels: Java13
> Attachments: SOLR-13580.patch
>
>
> ParsingFieldUpdateProcessorsTest has uncovered a JDK 13-ea+26 bug when
> dealing with the fr_FR Locale (which may affect other locales as well) which
> causes the grouping seperator ( U+00A0 in fr_FR ) to be ignored when parsing,
> treating them as a termination character -- example: "10 898" is parsed as
> "10" instead of "10898", leaving the " 898" portion of the string unparsed.
> The way the ParseNumeric UpdateProcessors are implemented, the fact that the
> NumbertFormat instance does not recognize the entire string as a Number
> results in the String value being left "as is" in the input documents.
> In ParsingFieldUpdateProcessorsTest this has manifested as jenkins failures
> like this...
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=ParsingFieldUpdateProcessorsTest
> -Dtests.method=testParseFloatNonRootLocale -Dtests.seed=AE6C840917DD963B
> -Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true
> -Dtests.locale=us -Dtests.timezone=GMT -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
> [junit4] FAILURE 0.03s |
> ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale <<<
> [junit4] > Throwable #1: java.lang.AssertionError
> [junit4] > at
> __randomizedtesting.SeedInfo.seed([AE6C840917DD963B:B5B079D8B7786A26]:0)
> [junit4] > at
> org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFloatNonRootLocale(ParsingFieldUpdateProcessorsTest.java:471)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit4] > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit4] > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit4] > at
> java.base/java.lang.reflect.Method.invoke(Method.java:567)
> [junit4] > at java.base/java.lang.Thread.run(Thread.java:830)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
