Hi Reto,
why this will affect also the interface?
Il 04/01/2013 10:17, Reto Bachmann-Gmür ha scritto:
Yes, I confirm. Thanks Giuseppe.
The bug affects the interface definition of Triple, not just the
implementation.
Cheers,
Reto
On Fri, Jan 4, 2013 at 10:06 AM, Tommaso Teofili
<tommaso.teof...@gmail.com>wrote:
Hi Giuseppe,
thanks a lot! This seems to me to be a bug (if anyone else feels I'm wrong
please chime in), feel free to open a Jira issue on
https://issues.apache.org/jira/browse/CLEREZZA and eventually attach a
patch.
Thanks again and have a nice day!
Tommaso
2013/1/4 Giuseppe Miscione <g.misci...@innovationengineering.eu>
Hi all,
I was looking at the hashCode implementation in the
org.apache.clerezza.rdf.core.**impl.TripleImpl and I found that this
method has this code:
public int hashCode() {
return (subject.hashCode() >> 1) ^ subject.hashCode() ^
(subject.hashCode() << 1);
}
This function uses only the subject of the triple. Wondering why only one
part of the triple is used, I looked at the implementation of the
corresponding class in the Jena library, and I found that there the
method
is implemented in this way:
public int hashCode() {
return (subject.hashCode() >> 1) ^ predicate.hashCode() ^
(object.hashCode() << 1);
}
And the reason is that in this way the triple (subject, predicate,
object)
has a differente hash code than (object, predicate, subject).
Now, it seems to be a small bug in the TripleImpl class. This error
doesn't prevent to use TripleImpl as keys in HashMaps because the
corresponding equals method is correct and coherent ( a.equals(b) =>
a.hashCode() == b.hashCode() ), but it can yield to performance
degradation
when storing a lot of triples with the same subject in an HashMap.
Regards,
Giuseppe
