[
https://issues.apache.org/jira/browse/GROOVY-10710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573178#comment-17573178
]
Paul King commented on GROOVY-10710:
------------------------------------
It would certainly be possible to do a few more up-front checks. Can you give
an example (failing case) where you think the behavior is broken?
Perhaps some kind of adapter backed by the original array would be better than
creating a new list(s). It would need to be smart enough to handle
multi-dimensional primitive arrays.
> operator == is broken for arrays
> --------------------------------
>
> Key: GROOVY-10710
> URL: https://issues.apache.org/jira/browse/GROOVY-10710
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
> Reporter: L
> Priority: Major
>
> To perform checks like a == b groovy runtime invokes method
> DefaultTypeTransformation.compareEqual(Object left, Object right).
> This method is OK if both the left side and the right side are arrays. But it
> is utterly broken if only one side of the comparison is an array:
> # There are calls to primitiveArrayToList() *before* making sure whether
> this is really necessary. This results in creation of most likely unnecessary
> objects (lists). It is much better to perform more checks like 'whether the
> other operand is a collection or array' and 'if so whether both left and
> right operand have the same size'.
> # The conversion with primitiveArrayToList() might also a break normal
> equals() implementation which compareEqual(Object left, Object right) falls
> back to if operands do not fall into the special cases. This is because the
> original operands *are replaced* with results of primitiveArrayToList() and
> equals() is invoked not on the original objects.
> This problem is present in the current 3.X, 4.X and 5.X versions of groovy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
