[
https://issues.apache.org/jira/browse/COMMONSRDF-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491029#comment-14491029
]
Peter Ansell commented on COMMONSRDF-14:
----------------------------------------
This may be a sticking point for some implementations which would like to
define hashCodes to fit their particular purposes. In particular, there is no
requirement in general that a hashCode utilise all relevant fields, as long as
it provides == hashCode ints for objects that are .equals. This has been taken
as a way to optimise hashCode generation and comparison for Literals, in
particular, an implementation may not using the type or language tag in the
hashCode, which is perfectly valid in the general case, as a Literal that is
.equals, will have the same label attached to it.
There also cannot be a contract on the hashCode for Triple without defining
hashCode for BlankNode, so that is not a simple extension if there is no
agreement on a universal identity for BlankNode, along with immutability for
BlankNode object. Both of those are not agreed on at this point, so it may be
useful to create a separate issue or issues for Triple and BlankNode.
> Define value returned by hashCode()
> -----------------------------------
>
> Key: COMMONSRDF-14
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-14
> Project: Apache Commons RDF
> Issue Type: Improvement
> Reporter: Reto Gmür
> Priority: Critical
>
> To allow interoperability the API must define what the hashCode for Literals
> and IRIs has to be. For grounded Triples the hashcode of instances of
> different implementations should also be equals, so the API should also
> define the hashcode of a triple as a function of the hashcode of its
> subjects, predicate and object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
