设计网站建设图片,cdr 做网站,用dw建设个人网站视频,外包做网站不满意因此#xff0c;当涉及到Java Collections API时#xff0c;我们倾向于认为已经了解了所有内容。 我们知道我们的身边方式列表 #xff0c; 设置 #xff0c; 地图 #xff0c; Iterables #xff0c; 迭代器 。 我们已经为Java 8的Collections API增强做好了准备。 但是… 因此当涉及到Java Collections API时我们倾向于认为已经了解了所有内容。 我们知道我们的身边方式列表 设置 地图 Iterables 迭代器 。 我们已经为Java 8的Collections API增强做好了准备。 但是随后我们偶尔会偶然发现其中一个奇怪的怪癖这些怪癖源于JDK的深度及其向后兼容的悠久历史。 让我们看看无法修改的集合 不可修改的收藏 Collections API不会反映集合是否可修改。 那里 不是不可变的List Set或Collection基类型可变的子类型可以扩展。 因此JDK中不存在以下API // Immutable part of the Collection API
public interface Collection {boolean contains(Object o);boolean containsAll(Collection? c);boolean isEmpty();int size();Object[] toArray();T T[] toArray(T[] array);
}// Mutable part of the Collection API
public interface MutableCollection
extends Collection {boolean add(E e);boolean addAll(Collection? extends E c);void clear();boolean remove(Object o);boolean removeAll(Collection? c);boolean retainAll(Collection? c);
} 现在可能有原因为什么在Java早期就没有以这种方式实现事情。 很有可能可变性不被视为值得在类型层次结构中占据其自身类型的功能。 因此出现了Collections帮助器类其中包含有用的方法例如unmodifiableList() unmodifiableSet() unmodifiableCollection()以及其他方法。 但是要当心使用不可修改的集合 Javadoc中提到了一个非常奇怪的事情 返回的集合不会将hashCode和equals操作传递到后备集合而是依赖于Object的equals和hashCode方法。 在后备集合是集合或列表的情况下必须保留这些操作的合同。 “保留这些行动的合同”。 那很模糊。 它背后的原因是什么 这个堆栈溢出答案给出了一个很好的解释 UnmodifiableList是UnmodifiableCollection但相反情况并非如此-包裹列表的UnmodifiableCollection不是UnmodifiableList。 因此如果将包装List a的UnmodifiableCollection与包装相同List a的UnmodifiableList进行比较则两个包装器不应相等。 如果只是传递给包装列表它们将是相等的。 尽管这种推理是正确的但其含义可能是出乎意料的。 底线 最重要的是您不能依赖Collection.equals() 。 虽然List.equals()和Set.equals()定义明确但不要信任Collection.equals() 。 它的行为可能没有意义。 当在方法签名中接受Collection时请记住这一点 public class MyClass {public void doStuff(Collection? collection) {// Dont rely on collection.equals() here!}
} 参考在JavaSQL和JOOQ博客上我们的JCG合作伙伴 Lukas Eder提出的Java Collections API怪癖 。 翻译自: https://www.javacodegeeks.com/2013/03/java-collections-api-quirks.html
