lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trejkaz <>
Subject Re: BytesRef violates the principle of least astonishment
Date Thu, 21 May 2015 06:29:36 GMT
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.)


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

View raw message