[
https://issues.apache.org/jira/browse/JCR-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545020
]
Marcel Reutegger commented on JCR-1232:
---------------------------------------
> public class UUIDNodeId extends UUID implements NodeId { ... }
I don't like this approach. Today we don't have a reason to introduce an
interface for NodeId and I would rather stay away from it as long as possible.
Otherwise we'll probably run into issues when it comes to equals methods:
- Is a UUIDNodeId equal to a UUID instance which contains the same value? What
about the other way around?
- What about other implementations of NodeId.
Well, basically the issues described by Joshua Bloch in Effective Java (Item 7:
Obey the general contract when overriding equals).
> 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.
