On Wed, May 20, 2015 at 5:12 PM, András Péteri <apet...@b2international.com> wrote: > As Olivier wrote, multiple BytesRef instances can share the underlying byte > array when representing slices of existing data, for performance reasons. > > BytesRef#clone()'s javadoc comment says that the result will be a shallow > clone, sharing the backing array with the original instance, and points > to another utility method for deep cloning: BytesRef#deepCopyOf(BytesRef).
I already know how Object#clone() works: "By convention, the object returned by this method should be independent of this object (which is being cloned). To achieve this independence, it may be necessary to modify one or more fields of the object returned by super.clone before returning it. Typically, this means copying any mutable objects that comprise the internal "deep structure" of the object being cloned and replacing the references to these objects with references to the copies." As BytesRef#clone() is overriding Object#clone(), I expect it to comply with that. Otherwise, it violates the Liskov substitution principle as well. Essentially, BytesRef cannot be used as an object. If Lucene wanted a shallow clone, it could have added shallowClone() while leaving clone() behaving correctly. I don't think that "it was for performance!" is an acceptable excuse for not wanting to name methods properly. Olivier Binda then says: > Lucene gives the user of the library the choice of how to use the data (which > is good) instead of creating immutable data for everybody and to make > people who don't need it suffer the penalty So basically, you make people who want reliable programs suffer the penalty. Awesome. TX --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
