lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: BytesRef violates the principle of least astonishment
Date Thu, 21 May 2015 15:20:20 GMT
bq: Anyways, really my main problem here is that the Migration Guide says:

Well, then volunteer to clarify them to prevent others from
experiencing your pain,
that's how open source code gets better.


On Wed, May 20, 2015 at 11:29 PM, Trejkaz <> wrote:
> On Thu, May 21, 2015 at 9:44 AM, Chris Hostetter
> <> wrote:
>> 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)
> Yep, this and other quirks are why I now prefer Guava's
> ImmutableList, ImmutableSet and ImmutableMap, where you never need
> to clone anyway.
> I guess in the case of ArrayList and friends, their excuse might have been
> that the list is supposed to support whatever object you want, and deep
> cloning would require that all objects you put in the list are cloneable.
> Maybe they weren't happy with requiring that. I don't really know.
> I know arrays are notoriously bad at this as well, but that's really just the
> tip of the iceberg when it comes to issues with arrays. (One could also
> complain about equals and hashCode not being implemented sensibly,
> the fact that they don't implement Iterable despite working in a foreach
> loop, the fact that stream() is absent, the fact that they don't all inherit
> from a common base class, and so on. I got sick of all this in arrays
> years ago and more or less switched entirely to using List as soon
> as generics became an option. But that's all history.)
> Anyways, really my main problem here is that the Migration Guide says:
>         "Note however that it can be costly to convert to String,
>          so it's better to work directly with the BytesRef."
> But it doesn't warn at all about the pitfalls of doing so. By the time I had
> discovered the pitfalls, I had already migrated 100% of our code which
> dealt with iterating TermEnum over to TermsEnum and had to redo all of
> it again.
> Well, this isn't the only thing missing from the migration guide anyway.
> I know there were other cases where a class had completely
> disappeared and there wasn't even a mention of it changing.
> (In the case of one of them, SortedVIntList, the changelog entry for it just
> mentioned it was being removed, not what the replacement was, so even
> people keen enough to read the *changelog* to find out what's going on
> are SOL.)
> TX
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message