Hi, in ZooKeeper-849[1] I proposed the introduction of a Path class and also provided a patch. However this patch has rightfully been rejected with the objection, that this represenation of paths at the server side would consume too much memory.
[1] https://issues.apache.org/jira/browse/ZOOKEEPER-849 Now I've a few ideas to still get a Path class and still save memory: - PathElement is a valid identifier for a Path level. PathElement holds a reference to Byte[] without ever leaking this reference. Byte[] is UTF-8 encoded. If you ever want to "see" the PathElement, it'll get converted to String. However most accesses to a PathElement a comparissions. - Path holds a List of PathElements. Concatenating this List with PATHSEPARATOR ("/") produces the Path - Path's Ctor is Path(List PathElement), convenience factories PathFactory.create(String|Byte[]) can be provided. - A special factory for PathElement caches PathElements it already created to reuse them. Thus two different Paths /a/b/c and /a/b/d will share the same PathElements "a" and "b". Not only will common prefixes be shared, but two paths /a/b/.lock and /c/d/.lock can share the same PathElement ".lock". - The lookup table for PathElement reusal may of course not prevent unused PathElements from being garbage collected by holding a strong reference to them. Thus we could use java.lang.ref.SoftReference[2] for the lookup table. [2] http://download.oracle.com/javase/1.5.0/docs/api/java/lang/ref/SoftReference.html Please give me your feedback about the general idea so that I could start implement it. Unrelated: Could some commiter please review ZOOKEEPER-837[3] "cyclic dependency ClientCnxn, ZooKeeper"? [3] https://issues.apache.org/jira/browse/ZOOKEEPER-837 (I'll also come back to work on Netty, but working on Netty requires full and long concentration, while I can hack on other things in shorter breaks.) Best regards, Thomas Koch, http://www.koch.ro
