cpugputpu created FLINK-16386:
---------------------------------

             Summary: Use LinkedHashMap in SqlFunctionUtils.java
                 Key: FLINK-16386
                 URL: https://issues.apache.org/jira/browse/FLINK-16386
             Project: Flink
          Issue Type: Bug
          Components: Table SQL / Runtime
            Reporter: cpugputpu


The test in 
_org.apache.flink.table.planner.expressions.ScalarFunctionsTest#testStringToMap_
 can fail due to a different iteration order of a HashMap. The failure is 
presented as follows.

_org.junit.ComparisonFailure: Wrong result for: [STR_TO_MAP(f46)] optimized 
to:[STR_TO_MAP($46)] 
expected:<\{test1=1, test2=2, test3=3}> but was:<\{test2=2, test1=1, test3=3}>_

The root cause of this issue lies in a HashMap initialized in 
SqlFunctionUtils.java, which makes no guarantee about the iteration order. A 
brief stack trace of the HashMap's iterator is presented here:

_java.util.HashMap$EntrySet.iterator(HashMap.java:1014)
org.apache.flink.table.dataformat.DataFormatConverters$MapConverter.toBinaryMap(DataFormatConverters.java:1174)
org.apache.flink.table.dataformat.DataFormatConverters$MapConverter.toInternalImpl(DataFormatConverters.java:1157)
org.apache.flink.table.dataformat.DataFormatConverters$MapConverter.toInternalImpl(DataFormatConverters.java:1114)
org.apache.flink.table.dataformat.DataFormatConverters$DataFormatConverter.toInternal(DataFormatConverters.java:290)
TestFunction$144.map(Unknown_ Source)
org.apache.flink.table.planner.expressions.utils.ExpressionTestBase.evaluateExprs(ExpressionTestBase.scala:152)

The specification about HashMap says that "this class makes no guarantees as to 
the order of the map; in particular, it does not guarantee that the order will 
remain constant over time". The documentation is here for your reference: 
[https://docs.oracle.com/javase/8/docs/api/java/util/HashMap.html]

The fix is to use LinkedHashMap instead of HashMap. In this way, the test will 
not suffer from failure any more and the code will be more stable, free of this 
non-deterministic behaviour.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to