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.
Best, Erick On Wed, May 20, 2015 at 11:29 PM, Trejkaz <trej...@trypticon.org> wrote: > On Thu, May 21, 2015 at 9:44 AM, Chris Hostetter > <hossman_luc...@fucit.org> 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) >> >> https://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html#clone%28%29 >> https://docs.oracle.com/javase/7/docs/api/java/util/HashSet.html#clone%28%29 >> https://docs.oracle.com/javase/7/docs/api/java/util/HashMap.html#clone%28%29 > > 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: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
