[
https://issues.apache.org/jira/browse/LUCENENET-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Paldino updated LUCENENET-284:
---------------------------------------
Attachment: EquatableListOfT.patch
Ok, I see where Andrei was coming from now. I introduced a bug in trying to
make the list comparable, when equitable was all that is needed.
If T doesn't implement IComparable, then an exception is thrown. If just
checking for equality and using EqualityComparer, then it does not rely on an
implementation of IEquatable, but will use it if it has one.
To that end, I've replaced ComparableList<T> with EquatableList<T> and removed
all the operators that have relative comparisons, but left the equals
comparisons and updated the patch to fix the places where the hash code was
being generated and the lists were being constructed. ComparableListOfT.patch
should not be used (and I'm removing it).
> java vs .Net GetHashCode and Equals for ArrayList
> --------------------------------------------------
>
> Key: LUCENENET-284
> URL: https://issues.apache.org/jira/browse/LUCENENET-284
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Andrei Iliev
> Attachments: ArrayList.patch, EquatableListOfT.patch
>
>
> 1)In java the hash code of a list (and ArrayList) is defined to be the result
> of the following calc:
> <code>
> hashCode = 1;
> Iterator i = list.iterator();
> while (i.hasNext()) {
> Object obj = i.next();
> hashCode = 31*hashCode + (obj==null ? 0 : obj.hashCode());
> }
> </code>
> In .Net it hash code of object itself.
>
> 2) In java two lists are defined to be equal if they contain the same
> elements in the same order.
> In .Net it compares the object references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
