gibt es den spliterator aus einem sortierten Strom eine Ausnahme

Question

Nach dem doc von Spliterator#getComparator wirft, heißt es

Wenn dieser Spliterator der Quelle SORTED durch ein Comparator ist, kehrt die Comparator. Wenn die Quelle SORTED in natürlicher Reihenfolge ist, wird null zurückgegeben. Andernfalls, wenn die Quelle nicht SORTED ist, wird IllegalStateException ausgelöst. Anforderungen

Umsetzung:

Die Standardimplementierung immer wirft IllegalStateException.

Rückgabe: a Comparator oder null wenn die Elemente in der natürlichen Reihenfolge sortiert sind.

Wirf: IllegalStateException - wenn der Spliterator keine Eigenschaft von SORTED meldet.

Also, wenn Sie dieses Stück Code ausgeführt

Spliterator<Integer> spliterator = Stream.of(1, 2, 3).sorted().spliterator(); 

System.out.println((spliterator.characteristics() & Spliterator.SORTED) == Spliterator.SORTED); 
System.out.println(spliterator.getComparator()); 

ich:

true 
null 

So weit so gut. Nun, wenn dies zu tun:

Spliterator<Integer> spliterator = Stream.of(1, 2, 3).sorted(Comparator.naturalOrder()).spliterator(); 

System.out.println((spliterator.characteristics() & Spliterator.SORTED) == Spliterator.SORTED); 
System.out.println(spliterator.getComparator()); 

Es gibt false und löst eine Ausnahme:

Exception in thread "main" java.lang.IllegalStateException 
    at java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.getComparator(StreamSpliterators.java:259) 
    at SpliteratorTest.main(SpliteratorTest.java:10) 

Warum ist es falsch ausgibt und löst eine Ausnahme?

Sollte es mir nicht die Comparator geben, die ich sorted() gemäß der Dokumentation lieferte?

(Dies geschieht auch mitoder comparing(identity()), usw.).

Answer 1

Interne Streams verwenden StreamOpFlag Enum, die etwas von Spliterator Flags unterscheidet. Flags werden unter Verwendung der Methode java.util.stream.StreamOpFlag.fromCharacteristics(Spliterator<?>) die umgewandelt Umsetzung ist die folgende:

static int fromCharacteristics(Spliterator<?> spliterator) { 
    int characteristics = spliterator.characteristics(); 
    if ((characteristics & Spliterator.SORTED) != 0 && spliterator.getComparator() != null) { 
     // Do not propagate the SORTED characteristic if it does not correspond 
     // to a natural sort order 
     return characteristics & SPLITERATOR_CHARACTERISTICS_MASK & ~Spliterator.SORTED; 
    } 
    else { 
     return characteristics & SPLITERATOR_CHARACTERISTICS_MASK; 
    } 
} 

Es scheint, dass die intern SORTED Kennlinie für den spliterator die für den Stream API nicht explizit natürlich geordnete nicht notwendig ist, so ist es nicht konserviert. Tatsächlich ist es nie in der Dokumentation angegeben, dass sorted(comparator).spliterator() den Spliterator mit SORTED Eigenschaft zurückgeben muss. Die Spliterator-Dokumentation sagt, dass, wenn es SORTED Eigenschaft hat, muss es den Komparator zurückgeben, aber es gibt keinen Fall, wenn das SORTED Merkmal erforderlich ist, also ist es bis zur Implementierung. Das kann sich in Zukunft ändern, aber es ist kein Fehler.

Update: habe gerade bemerkt, dass in JDK-9 gibt es eine klare Aussage added in die Dokumentation von spliterator() Methode:

Der zurück spliterator die Reihe von Merkmalen aus dem Stream-Pipeline abgeleitet berichten sollte (nämlich die Eigenschaften, die von dem Stromquellen-Spliterator und den Zwischenoperationen abgeleitet sind). Implementierungen können eine Untergruppe dieser Merkmale melden. Zum Beispiel kann es zu teuer sein, das gesamte Set für einige oder alle möglichen Stream-Pipelines zu berechnen.

Siehe JDK-8048689 Fehlerbericht.

Answer 2

Ich denke, das ist ein Fehler in Oracle JDK (1.8.0_45).

Wenn Sie einen Stream machen mit Stream#sorted() natürlichen Reihenfolge sortiert verwenden, wickelt es intern den Strom in einem SortedOps.OfRef den folgenden Konstruktor:

OfRef(AbstractPipeline<?, T, ?> upstream) { 
     super(upstream, StreamShape.REFERENCE, 
       StreamOpFlag.IS_ORDERED | StreamOpFlag.IS_SORTED); 
    ... 

Wenn Sie eine benutzerdefinierte Comparator mit Stream#sorted(Comparator) geben, tut es das gleiche sondern verwendet den folgenden Konstruktor statt:

OfRef(AbstractPipeline<?, T, ?> upstream, Comparator<? super T> comparator) { 
     super(upstream, StreamShape.REFERENCE, 
       StreamOpFlag.IS_ORDERED | StreamOpFlag.NOT_SORTED); 
    ... 

die StreamOpFlag.NOT_SORTED soll die SORTED fl löschen ag, falls es vorher eingestellt wurde. Dies bedeutet, dass ein sortierter Stream nach dieser Operation zu einem nicht sortierten Stream wird.

Ich denke, es könnte anstelle von StreamOpFlag.IS_SORTED und der super() Aufruf sollte die gleichen Parameter wie im ersten Konstruktor verwendet werden.

Ich konnte jedoch kein entsprechendes Problem im Java Bug System finden.