lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: BytesRef violates the principle of least astonishment
Date Wed, 20 May 2015 23:44:11 GMT

: I already know how Object#clone() works:

May i humbly suggest that you: a) relax a bit; b) keep reading the 
rest of the javadocs for that method?

: As BytesRef#clone() is overriding Object#clone(), I expect it to
: comply with that.

BytesRef#clone() functions virtually identical to the way Object#clone 
functions, as noted in the *remainder* of the method javadocs you 

>> ...this method creates a new instance of the class of this object and 
>> initializes all its fields with exactly the contents of the corresponding 
>> fields of this object, as if by assignment; the contents of the fields 
>> are not themselves cloned. Thus, this method performs a "shallow copy" 
>> of this object, not a "deep copy" operation.

...regardless of what convention is *suggested*, BytesRef behaves in the 
manor consistent with Object#clone, and in the manor consistent with the 
*purpose* of the class (to be a *Reference*) and in the manor that gives 
the most flexibility for it's use -- if it did a deep clone by default, we 
might as well just use byte[] everywhere in the API.

: Essentially, BytesRef
: cannot be used as an object.
: If Lucene wanted a shallow clone, it could have added shallowClone() while

If you really feel strongly about this, and want to advocate for more 
consistency arround the meaning/implementation of "clone()" in Java APIs, 
i suggest you take it up with the Open JDK project, and focus on a more 
high visibility, widely used (in the Java community as a whole) 
class, such as ArrayList, HashSet, or HashMap etc...  (all of which 
implement Clonable, and all of which are documented as implementing 
Object#clone by making a shallow copy)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message