lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toke Eskildsen ...@statsbiblioteket.dk>
Subject Re: BytesRef violates the principle of least astonishment
Date Wed, 20 May 2015 12:35:28 GMT
On Wed, 2015-05-20 at 09:12 +0200, András Péteri 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).

There is no hard contract for clone
https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#clone%
28%29
but the convention, as stated, is "the object returned by this method
should be independent of this object". That whole section of the
Oracle's JavaDocs describes the exact opposite of BytesRef clone
behaviour.

It really should have been the other way around, with BytesRef#clone
being deep and loyal to convention and the special method being
BytesRef#shallowCopyOf(BytesRef).


But we are where we are, so I don't find it viable to change behaviour.
More explicit documentation, as Dawid suggests, seems the best band aid.

- Toke Eskildsen, State and University Library, Denmark



---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message