[
https://issues.apache.org/jira/browse/JCR-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462176
]
Tobias Bocanegra commented on JCR-680:
--------------------------------------
I agreed with stefan that it's a bit hard to understand how it works.
especially because the inner classes modify the field of the GenericValue.
however, it seems to make the other values classes much leaner :-) and the
stream/value ambiguity is nicely solved this this pattern.
to only thing i'm not happy with is the 'equals()' and 'hashCode()'
implementation. hashcode should cache the code, and i suggest that equals
delegates to the values. for example it might result in very poor performance
if 2 date values always need to convert to string for comparison:
public boolean equals(Object other) {
if (this == other) {
return true;
}
if (other instanceof GenericValue) {
GenericValue o = (GenericValue) other;
return o.value == value || value.equals(o.value);
} else if (other instanceof Value) {
return value.equals((Value) other);
} else {
return false;
}
}
and have all the optimized equals in the value classes.
> Improve the Value implementation
> --------------------------------
>
> Key: JCR-680
> URL: https://issues.apache.org/jira/browse/JCR-680
> Project: Jackrabbit
> Issue Type: Improvement
> Components: core
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Attachments: class.jpg, GenericValue.patch, GenericValue.tar.gz,
> JCR-680.patch
>
>
> The current Value implementation found in jackrabbit-jcr-commons has some
> deficiencies like Value.equals() being incorrect in some cases (see for
> example JCR-320), and Name and Path values not following namespace remappings.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
