Strumień.pomiń zachowanie z nieuporządkowaną operacją terminala

Przeczytałem już to i to pytania, ale nadal wątpimy, czy obserwowane zachowanie Stream.skip było zamierzone przez autorów JDK.

Niech będzie proste wprowadzenie liczb 1..20:

List<Integer> input = IntStream.rangeClosed(1, 20).boxed().collect(Collectors.toList());

Teraz stwórzmy równoległy strumień, połączmy unordered() z skip() na różne sposoby i zbierzmy wynik:

System.out.println("skip-skip-unordered-toList: "
        + input.parallelStream().filter(x -> x > 0)
            .skip(1)
            .skip(1)
            .unordered()
            .collect(Collectors.toList()));
System.out.println("skip-unordered-skip-toList: "
        + input.parallelStream().filter(x -> x > 0)
            .skip(1)
            .unordered()
            .skip(1)
            .collect(Collectors.toList()));
System.out.println("unordered-skip-skip-toList: "
        + input.parallelStream().filter(x -> x > 0)
            .unordered()
            .skip(1)
            .skip(1)
            .collect(Collectors.toList()));

Filtrowanie krok zasadniczo nic tutaj, ale dodaje więcej trudności dla stream engine: teraz nie zna dokładnej wielkości wyjście, dlatego niektóre optymalizacje są wyłączone. Mam następujące wyniki:

skip-skip-unordered-toList: [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]
// absent values: 1, 2
skip-unordered-skip-toList: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, 18, 19, 20]
// absent values: 1, 15
unordered-skip-skip-toList: [1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 20]
// absent values: 7, 18

Wyniki są całkowicie w porządku, wszystko działa zgodnie z oczekiwaniami. W pierwszym przypadku poprosiłem o pominięcie pierwszych dwóch elementów, a następnie zebrać do listy w żadnej konkretnej kolejności. W drugim przypadku poprosiłem o pominięcie pierwszego elementu, a następnie przejście na unordered i pominięcie jeszcze jednego elementu (nie obchodzi mnie który). W trzecim przypadku najpierw przełączyłem się w tryb nieuporządkowany, a następnie pominąłem dwa dowolne elementy.

Let ' s pomiń jeden element i zbierz do kolekcji niestandardowej w trybie nieuporządkowanym. Nasza kolekcja będzie HashSet:

System.out.println("skip-toCollection: "
        + input.parallelStream().filter(x -> x > 0)
        .skip(1)
        .unordered()
        .collect(Collectors.toCollection(HashSet::new)));

Wynik jest zadowalający:

skip-toCollection: [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]
// 1 is skipped

Więc generalnie spodziewam się, że dopóki stream jest uporządkowany, skip() pomija pierwsze elementy, w przeciwnym razie pomija dowolne.

Jednak użyjmy równoważnej, nieuporządkowanej operacji terminala collect(Collectors.toSet()):

System.out.println("skip-toSet: "
        + input.parallelStream().filter(x -> x > 0)
            .skip(1)
            .unordered()
            .collect(Collectors.toSet()));

Teraz wyjście to:

skip-toSet: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 16, 17, 18, 19, 20]
// 13 is skipped

Ten sam wynik można osiągnąć z każdym innym nieuporządkowane działanie terminala (jak forEach, findAny, anyMatch, itd.). Usunięcie unordered() kroku w tym przypadku nic nie zmienia. Wygląda na to, że podczas gdy unordered() step poprawnie powoduje, że strumień nie jest uporządkowany od bieżącej operacji, operacja terminala nie jest uporządkowana od samego początku, mimo że może to wpłynąć na wynik, jeśli skip() została użyta. Wydaje mi się to całkowicie mylące: spodziewam się, że użycie nieuporządkowanego kolektora jest tym samym, co Zamiana strumienia w tryb nieuporządkowany tuż przed operacją terminala i używając równoważnego uporządkowanego kolektora.

Więc moje pytania to:

1. czy to zachowanie jest zamierzone, czy to błąd?
2. jeśli tak, czy jest to gdzieś udokumentowane? Przeczytałem Stream.skip () dokumentacja: nie mówi nic o nieuporządkowanych operacjach terminala. Również Cechy.UNORDERED dokumentacja nie jest zbyt zrozumiała i nie mówi, że zamówienie zostanie utracone dla całego strumień. Na koniec sekcja uporządkowanie w podsumowaniu pakietu również nie obejmuje tego przypadku. Pewnie coś przeoczyłem?
3. jeśli jest to zamierzone, że niezaordowana operacja terminala sprawia, że cały strumień jest niezaordowany, dlaczego unordered() krok sprawia, że jest niezaordowany dopiero od tego momentu? Czy mogę polegać na takim zachowaniu? Czy po prostu miałem szczęście, że moje pierwsze testy działają dobrze?