[
https://issues.apache.org/jira/browse/JCR-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545031
]
Thomas Mueller commented on JCR-1232:
-------------------------------------
In my view duplicating source code is worse than adding an interface, but
NodeId extends UUID would be a solution as well.
> Is a UUIDNodeId equal to a UUID instance which contains the same value? What
> about the other way around?
I don't think the current situation is much different. NodeId equals should
return false when comparing with any other class. Similar to Short.equals: One
could argue the equals should return true when comparing with Short(1) with
Integer(1), but it does not:
public boolean equals(Object obj) {
if (obj instanceof Short) {
return value == ((Short)obj).shortValue();
}
return false;
}
> Merge UUID to NodeId
> --------------------
>
> Key: JCR-1232
> URL: https://issues.apache.org/jira/browse/JCR-1232
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Reporter: Jukka Zitting
> Priority: Minor
> Attachments: nodeid.patch
>
>
> The current NodeId class is mostly just a wrapper around UUID, which causes
> two objects to be instantiated for each node identifier that the system uses.
> The memory and processing overhead is quite small, but given that there are
> tons of NodeId instances it would be good to eliminate that overhead.
> There is also lots of code that just converts UUIDs to NodeIds and vice
> versa. We could simplify such code if we just used NodeId everywhere.
> Also, we might want to open up the possibility of using non-UUID node
> identifiers at some point in future, so it would make a lot of sense to
> remove the NodeId.getUUID method and rely directly on NodeId and it's
> equals(), hashCode(), and toString() methods in many places where we
> currently use UUIDs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
