Почему пустые коллекции разного типа равны?

Question

Какой механизм ниже делает равными разные типы?

import static org.testng.Assert.assertEquals;

@Test
public void whyThisIsEqual() {
    assertEquals(new HashSet<>(), new ArrayList<>());
}

Answer 1

Testng вызывает метод, реализованный таким образом.

  public static void assertEquals(Collection<?> actual, Collection<?> expected, String message) {
    if (actual == expected) {
      return;
    }

    if (actual == null || expected == null) {
      if (message != null) {
        fail(message);
      } else {
        fail("Collections not equal: expected: " + expected + " and actual: " + actual);
      }
    }

    assertEquals(
        actual.size(),
        expected.size(),
        (message == null ? "" : message + ": ") + "lists don't have the same size");

    Iterator<?> actIt = actual.iterator();
    Iterator<?> expIt = expected.iterator();
    int i = -1;
    while (actIt.hasNext() && expIt.hasNext()) {
      i++;
      Object e = expIt.next();
      Object a = actIt.next();
      String explanation = "Lists differ at element [" + i + "]: " + e + " != " + a;
      String errorMessage = message == null ? explanation : message + ": " + explanation;
      assertEqualsImpl(a, e, errorMessage);
    }
  }

Это пытается быть полезным, но плохо по ряду причин.

Две равные коллекции могут казаться разными.

Set<Integer> a = new HashSet<>();
a.add(82);
a.add(100);
System.err.println(a);
Set<Integer> b = new HashSet<>();
for (int i = 82; i <= 100; i++)
    b.add(i);
for (int i = 83; i <= 99; i++)
    b.remove(i);
System.err.println(b);
System.err.println("a.equals(b) && b.equals(a) is " + (a.equals(b) && b.equals(a)));
assertEquals(a, b, "a <=> b");

и

Set<Integer> a = new HashSet<>();
a.add(100);
a.add(82);
System.err.println(a);
Set<Integer> b = new HashSet<>(32);
b.add(100);
b.add(82);
System.err.println(b);
System.err.println("a.equals(b) && b.equals(a) is " + (a.equals(b) && b.equals(a)));
assertEquals(a, b, "a <=> b");

печать

[82, 100]
[100, 82]
a.equals(b) && b.equals(a) is true
Exception in thread "main" java.lang.AssertionError: a <=> b: Lists differ at element [0]: 100 != 82
    at ....

Две коллекции могут быть одинаковыми или разными в зависимости от того, как они сравниваются.

assertEquals(a, (Iterable) b); // passes

assertEquals(a, (Object) b); // passes

assertEquals(Arrays.asList(a), Arrays.asList(b)); // passes

Answer 2

Когда я запускаю код ниже, условие false.

if( (new HashSet<>()).equals(new ArrayList<>())){
            System.out.println("They are equal");
        }

Следовательно, для assertEquals, true проверяет только элементы и их порядок на равенство. Но для equals это ложно .

Answer 3

Документация assertEquals(Collection<?> actual, Collection<?> expected) гласит:

Утверждает, что две коллекции содержат одинаковые элементы в одинаковом порядке. Если нет, выдается ошибка AssertionError.

Таким образом, сравнивается содержимое коллекций, которые в случае, если обе коллекции пусты, равны.

Answer 4

Они не ...

System.out.println(new HashSet<>().equals(new ArrayList<>())); // false

Это относится только к testng assertEquals

Глядя на документацию этого метода, он говорит:

Утверждает, что две коллекции содержат одинаковые элементы в одинаковом порядке.

И это смешно для меня, у Set нет порядка, как такового.

Set<String> set = new HashSet<>();
set.add("hello");
set.add("from");
set.add("jug");

System.out.println(set); // [from, hello, jug]

IntStream.range(0, 1000).mapToObj(x -> x + "").forEachOrdered(set::add);
IntStream.range(0, 1000).mapToObj(x -> x + "").forEachOrdered(set::remove);

System.out.println(set); // [jug, hello, from]

Таким образом, сравнение их с Collection в некотором конкретном моменте времени даст интересные результаты.

Еще хуже, методы java-9 Set::of реализуют внутреннюю рандомизацию, поэтому порядок (или не порядок) будет отличаться от прогона к прогону.

Answer 5

Поскольку сравнивается только содержимое коллекции, а не тип коллекции.

Обоснование этого заключается в том, что часто некоторый подкласс коллекции возвращается из проверенного метода и не имеет значения, какой именно подкласс используется.