심층 분할기 특성 이해

심층 분할기 특성 이해

---

Java 스트림과 분할자를 깊이 이해하기 위해 분할기 특성 에 대한 미묘한 질문이 있습니다 .

Q1 : Stream.empty()vsStream.of() (인수없는 Stream.of ())

• Stream.empty(): SUBSIZED, SIZED
• Stream.of(): SUBSIZED, IMMUTABLE , SIZED, ORDERED

왜 Stream.empty()동일한 특성이 Stream.of()없습니까? Stream.concat ()과 함께 사용할 때 영향을줍니다 (특히는 포함하지 않음 ORDERED). IMMUTABLE 및 ORDERED 뿐만 아니라 DISTINCT 및 NONNULL 도 Stream.empty()있어야 한다고 말하고 싶습니다 . 또한 DISTICT를 갖는 하나의 인수만으로도 의미 가 있습니다.Stream.of()

Q2 : NONNULLLongStream.of() 이 없음

NONNULL은에서 사용할 수 없습니다 LongStream.of. 하지 NONNULL모두의 주요 특징 LongStream들, IntStreams와 DoubleStream의?

Q3 : LongStream.range(,)대LongStream.range(,).boxed()

• LongRange.range(,): SUBSIZED, IMMUTABLE, NONNULL, SIZED , ORDERED, SORTED, DISTINCT
• LongStream.range(,).boxed(): SUBSIZED, SIZED, ORDERED

.boxed()이러한 모든 특성을 잃는 이유 는 무엇 입니까? 잃어 버려서는 안됩니다.

나는 NONNULL, IMMUTABLE 및 DISTICT를.mapToObj() 잃을 수 있음을 이해 하지만 ... 이치에 맞지 않습니다..boxed()

Q4 : IMMUTABLE 및 NONNULL.peek() 손실

LongStream.of(1): SUBSIZED, IMMUTABLE, NONNULL, SIZED, ... LongStream.of(1).peek() : SUBSIZED, SIZED, ...

.peek()이러한 특성을 잃는 이유 는 무엇 입니까? .peek정말로 잃어 버려서는 안됩니다.

Q5 : .skip(), SUBSIZED, IMMUTABLE, NONNULL, SIZED.limit() 손실

이러한 작업은 SUBSIZED, IMMUTABLE, NONNULL, SIZED 손실 됩니다. 왜? 크기를 사용할 수있는 경우 최종 크기도 쉽게 계산할 수 있습니다.

Q6 : IMMUTABLE, NONNULL.filter() 손실

이 작업은 SUBSIZED, IMMUTABLE, NONNULL, SIZED 손실됩니다 . SUBSIZED 및 SIZED 를 잃는 것은 이치에 맞지만 나머지 두 가지는 말이되지 않습니다. 왜?

---

분할기를 깊이 이해하는 사람이 명확성을 가져올 수 있다면 감사하겠습니다. 감사.

---

처음에 특성의 실제 의미를 알아 내려고했을 때도 어려움이 있었고, Java 8 구현 단계에서 그 의미가 명확하게 정해지지 않았고 그 이유로 일관성없이 사용된다는 느낌이 들었다는 사실을 인정해야합니다.

고려 Spliterator.IMMUTABLE:

요소 소스를 구조적으로 수정할 수 없음을 나타내는 특성 값. 즉, 요소를 추가, 교체 또는 제거 할 수 없으므로 순회 중에 이러한 변경이 발생할 수 없습니다.

그것은 "대체"보고 이상하다 (A)의 말할 때 일반적으로 구조적인 변경으로 간주되지 않습니다이 목록에서 List또는 배열 결과적으로, 스트림 (복제되지 않음) 배열을 수용 spliterator 공장 보고서 IMMUTABLE와 같은, LongStream.of(…)또는 Arrays.spliterator(long[]).

이를 "클라이언트가 관찰 할 수없는 한"으로 더 관대하게 해석하면 CONCURRENT두 경우 모두 순회 중에 추가되었는지 여부를 인식 할 방법없이 일부 요소가 클라이언트에보고 되므로와 큰 차이가 없습니다. 분할기를 되 감고 비교할 방법이 없기 때문에 일부는 제거로 인해보고되지 않았습니다.

사양은 계속됩니다.

보고하지 않는 Spliterator IMMUTABLE또는 CONCURRENT(예를 던지는에 대한 문서화 된 정책을 것으로 예상된다 ConcurrentModificationException구조적 간섭에 관한)을 통과하는 동안 발견했습니다.

그리고 그 중 하나가 리포팅 spliterator은에만 해당 일이, IMMUTABLE나 CONCURRENT,가 던져 결코 보장된다 ConcurrentModificationException. 물론 의미 론적으로 CONCURRENT배제 SIZED하지만 클라이언트 코드에는 영향을 미치지 않습니다.

실제로 이러한 특성은 Stream API의 어떤 항목에도 사용되지 않으므로 일관성없이 사용하면 어딘가에서 눈에 띄지 않습니다.

이것은 또한 모든 중간 작업이 CONCURRENT, IMMUTABLE및 NONNULL특성 을 지우는 효과가있는 이유를 설명 합니다. Stream 구현은이를 사용하지 않으며 스트림 상태를 나타내는 내부 클래스는이를 유지하지 않습니다.

---

마찬가지로 NONNULL어디에도 사용되지 않으므로 특정 스트림에 대한 부재는 효과가 없습니다. 나는 추적 할 수 LongStream.of(…)의 내부 사용에 문제 아래 Arrays.spliterator(long[], int, int)있는 대표로를
Spliterators.spliterator​(long[] array, int fromIndex, int toIndex, int additionalCharacteristics):

반환 된 분할자는 항상 특성 SIZED및 SUBSIZED. 호출자는 분할자가보고 할 추가 특성을 제공 할 수 있습니다. (예를 들어, 배열이 더 이상 수정되지 않는 것으로 알려진 IMMUTABLE경우, 배열 데이터에 발생 순서가있는 것으로 간주되는 경우를 지정 ORDERED하십시오.) 이 방법은 Arrays.spliterator(long[], int, int)자주보고합니다 spliterator를 반환하는 대신 사용할 수 있습니다 SIZED, SUBSIZED, IMMUTABLE,와 ORDERED.

(다시) IMMUTABLE특성 의 일관성없는 사용에 유의하십시오 . 그것은 다시하면서 동시에, 보증에 대한 수정의 부재를 가진처럼 취급 Arrays.spliterator차례로 Arrays.stream및 LongStream.of(…)보고서됩니다 IMMUTABLE발신자가 자신의 배열을 수정하지 않습니다 것을 보증 할 수없이, 심지어 사양에 의해, 특성을. 요소를 구조적 수정이 아닌 것으로 설정하는 것을 고려하지 않는 한, 배열을 구조적으로 수정할 수 없기 때문에 전체 구분이 다시 무의미 해집니다.

그리고 그것은 분명히 어떤 NONNULL특성도 명시하지 않았습니다 . 원시 값이 될 수없는 것은 명백하지만 null, 상기 Spliterator.Abstract<Primitive>Spliterator클래스는 변함 분사 NONNULL특성의 spliterator 의해 리턴 Spliterators.spliterator​(long[],int,int,int)상속되지 않는다 Spliterator.AbstractLongSpliterator.

나쁜 점은 사양을 변경하지 않고는 고칠 수 없다는 것입니다. 좋은 점은 어쨌든 결과가 없다는 것입니다.

---

로 우리가 어떤 문제를 무시한다면 CONCURRENT, IMMUTABLE또는 NONNULL어떤 결과를 가져올없는, 우리가

SIZED및 skip& limit. 이것은 잘 알려진 문제입니다, 방법의 결과 skip와 limit스트림 API에 의해 구현되었다. 다른 구현도 상상할 수 있습니다. 이는 limit예측 가능한 크기를 가져야하지만 현재 구현에서는 그렇지 않은 무한 스트림의 조합에도 적용됩니다 .

결합 Stream.concat(…)과 함께 Stream.empty(). 빈 스트림이 결과 순서에 제약을 부과 하지 않는 것이 합리적으로 들립니다 . 그러나 Stream.concat(…)하나의 입력에만 주문이 없을 때 주문을 해제하는 행위는 의문입니다. 주문과 관련하여 너무 공격적인 것은 새로운 것이 아닙니다. 처음에는 의도적 인 것으로 간주되었지만 Java 8, 업데이트 60까지 늦게 수정 된 동작에 관한 이 Q & A 를 참조하십시오 . 아마도이 Stream.concat시점에서 바로 논의되어야 할 것입니다 . …

The behavior of .boxed() is easy to explain. When it has been implemented naively like .mapToObj(Long::valueOf), it will simply loose all the knowledge, as mapToObj can not assume that the result is still sorted or distinct. But this has been fixed with Java 9. There, LongStream.range(0,10).boxed() has SUBSIZED|SIZED|ORDERED|SORTED|DISTINCT characteristics, maintaining all characteristics that have relevance to the implementation.

ReferenceURL : https://stackoverflow.com/questions/46644595/understanding-deeply-spliterator-characteristics