[
https://issues.apache.org/jira/browse/GROOVY-10710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573438#comment-17573438
]
L commented on GROOVY-10710:
----------------------------
Yes, it is in fact more of memory and performance related issue. At least this
is how we got hit by it: we had quite a large byte[] that sort of by mistake
ended up used in == comparison with a different object (not an array or
collection). Sure we have fixed our code after we have realized why our script
was failing so spectacularly. But this is a very easy mistake to make.
So using an adapter/wrapper class is really a good idea.
The second part of the issue (broken "equals") is not what we have experienced.
This is what I have concluded just by studying "compareEqual" method. Surely
this also have to be fixed.
> 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)
