< prev index next >

jdk/src/java.base/share/classes/java/util/stream/LongStream.java

Print this page




 310      *
 311      * @apiNote
 312      * While {@code takeWhile()} is generally a cheap operation on sequential
 313      * stream pipelines, it can be quite expensive on ordered parallel
 314      * pipelines, since the operation is constrained to return not just any
 315      * valid prefix, but the longest prefix of elements in the encounter order.
 316      * Using an unordered stream source (such as
 317      * {@link #generate(LongSupplier)}) or removing the ordering constraint with
 318      * {@link #unordered()} may result in significant speedups of
 319      * {@code takeWhile()} in parallel pipelines, if the semantics of your
 320      * situation permit.  If consistency with encounter order is required, and
 321      * you are experiencing poor performance or memory utilization with
 322      * {@code takeWhile()} in parallel pipelines, switching to sequential
 323      * execution with {@link #sequential()} may improve performance.
 324      *
 325      * @param predicate a <a href="package-summary.html#NonInterference">non-interfering</a>,
 326      *                  <a href="package-summary.html#Statelessness">stateless</a>
 327      *                  predicate to apply to elements to determine the longest
 328      *                  prefix of elements.
 329      * @return the new stream
 330      * @since 1.9
 331      */
 332     default LongStream takeWhile(LongPredicate predicate) {
 333         Objects.requireNonNull(predicate);
 334         // Reuses the unordered spliterator, which, when encounter is present,
 335         // is safe to use as long as it configured not to split
 336         return StreamSupport.longStream(
 337                 new WhileOps.UnorderedWhileSpliterator.OfLong.Taking(spliterator(), true, predicate),
 338                 isParallel()).onClose(this::close);
 339     }
 340 
 341     /**
 342      * Returns, if this stream is ordered, a stream consisting of the remaining
 343      * elements of this stream after dropping the longest prefix of elements
 344      * that match the given predicate.  Otherwise returns, if this stream is
 345      * unordered, a stream consisting of the remaining elements of this stream
 346      * after dropping a subset of elements that match the given predicate.
 347      *
 348      * <p>If this stream is ordered then the longest prefix is a contiguous
 349      * sequence of elements of this stream that match the given predicate.  The
 350      * first element of the sequence is the first element of this stream, and


 377      *
 378      * @apiNote
 379      * While {@code dropWhile()} is generally a cheap operation on sequential
 380      * stream pipelines, it can be quite expensive on ordered parallel
 381      * pipelines, since the operation is constrained to return not just any
 382      * valid prefix, but the longest prefix of elements in the encounter order.
 383      * Using an unordered stream source (such as
 384      * {@link #generate(LongSupplier)}) or removing the ordering constraint with
 385      * {@link #unordered()} may result in significant speedups of
 386      * {@code dropWhile()} in parallel pipelines, if the semantics of your
 387      * situation permit.  If consistency with encounter order is required, and
 388      * you are experiencing poor performance or memory utilization with
 389      * {@code dropWhile()} in parallel pipelines, switching to sequential
 390      * execution with {@link #sequential()} may improve performance.
 391      *
 392      * @param predicate a <a href="package-summary.html#NonInterference">non-interfering</a>,
 393      *                  <a href="package-summary.html#Statelessness">stateless</a>
 394      *                  predicate to apply to elements to determine the longest
 395      *                  prefix of elements.
 396      * @return the new stream
 397      * @since 1.9
 398      */
 399     default LongStream dropWhile(LongPredicate predicate) {
 400         Objects.requireNonNull(predicate);
 401         // Reuses the unordered spliterator, which, when encounter is present,
 402         // is safe to use as long as it configured not to split
 403         return StreamSupport.longStream(
 404                 new WhileOps.UnorderedWhileSpliterator.OfLong.Dropping(spliterator(), true, predicate),
 405                 isParallel()).onClose(this::close);
 406     }
 407 
 408     /**
 409      * Performs an action for each element of this stream.
 410      *
 411      * <p>This is a <a href="package-summary.html#StreamOps">terminal
 412      * operation</a>.
 413      *
 414      * <p>For parallel stream pipelines, this operation does <em>not</em>
 415      * guarantee to respect the encounter order of the stream, as doing so
 416      * would sacrifice the benefit of parallelism.  For any given element, the
 417      * action may be performed at whatever time and in whatever thread the




 310      *
 311      * @apiNote
 312      * While {@code takeWhile()} is generally a cheap operation on sequential
 313      * stream pipelines, it can be quite expensive on ordered parallel
 314      * pipelines, since the operation is constrained to return not just any
 315      * valid prefix, but the longest prefix of elements in the encounter order.
 316      * Using an unordered stream source (such as
 317      * {@link #generate(LongSupplier)}) or removing the ordering constraint with
 318      * {@link #unordered()} may result in significant speedups of
 319      * {@code takeWhile()} in parallel pipelines, if the semantics of your
 320      * situation permit.  If consistency with encounter order is required, and
 321      * you are experiencing poor performance or memory utilization with
 322      * {@code takeWhile()} in parallel pipelines, switching to sequential
 323      * execution with {@link #sequential()} may improve performance.
 324      *
 325      * @param predicate a <a href="package-summary.html#NonInterference">non-interfering</a>,
 326      *                  <a href="package-summary.html#Statelessness">stateless</a>
 327      *                  predicate to apply to elements to determine the longest
 328      *                  prefix of elements.
 329      * @return the new stream
 330      * @since 9
 331      */
 332     default LongStream takeWhile(LongPredicate predicate) {
 333         Objects.requireNonNull(predicate);
 334         // Reuses the unordered spliterator, which, when encounter is present,
 335         // is safe to use as long as it configured not to split
 336         return StreamSupport.longStream(
 337                 new WhileOps.UnorderedWhileSpliterator.OfLong.Taking(spliterator(), true, predicate),
 338                 isParallel()).onClose(this::close);
 339     }
 340 
 341     /**
 342      * Returns, if this stream is ordered, a stream consisting of the remaining
 343      * elements of this stream after dropping the longest prefix of elements
 344      * that match the given predicate.  Otherwise returns, if this stream is
 345      * unordered, a stream consisting of the remaining elements of this stream
 346      * after dropping a subset of elements that match the given predicate.
 347      *
 348      * <p>If this stream is ordered then the longest prefix is a contiguous
 349      * sequence of elements of this stream that match the given predicate.  The
 350      * first element of the sequence is the first element of this stream, and


 377      *
 378      * @apiNote
 379      * While {@code dropWhile()} is generally a cheap operation on sequential
 380      * stream pipelines, it can be quite expensive on ordered parallel
 381      * pipelines, since the operation is constrained to return not just any
 382      * valid prefix, but the longest prefix of elements in the encounter order.
 383      * Using an unordered stream source (such as
 384      * {@link #generate(LongSupplier)}) or removing the ordering constraint with
 385      * {@link #unordered()} may result in significant speedups of
 386      * {@code dropWhile()} in parallel pipelines, if the semantics of your
 387      * situation permit.  If consistency with encounter order is required, and
 388      * you are experiencing poor performance or memory utilization with
 389      * {@code dropWhile()} in parallel pipelines, switching to sequential
 390      * execution with {@link #sequential()} may improve performance.
 391      *
 392      * @param predicate a <a href="package-summary.html#NonInterference">non-interfering</a>,
 393      *                  <a href="package-summary.html#Statelessness">stateless</a>
 394      *                  predicate to apply to elements to determine the longest
 395      *                  prefix of elements.
 396      * @return the new stream
 397      * @since 9
 398      */
 399     default LongStream dropWhile(LongPredicate predicate) {
 400         Objects.requireNonNull(predicate);
 401         // Reuses the unordered spliterator, which, when encounter is present,
 402         // is safe to use as long as it configured not to split
 403         return StreamSupport.longStream(
 404                 new WhileOps.UnorderedWhileSpliterator.OfLong.Dropping(spliterator(), true, predicate),
 405                 isParallel()).onClose(this::close);
 406     }
 407 
 408     /**
 409      * Performs an action for each element of this stream.
 410      *
 411      * <p>This is a <a href="package-summary.html#StreamOps">terminal
 412      * operation</a>.
 413      *
 414      * <p>For parallel stream pipelines, this operation does <em>not</em>
 415      * guarantee to respect the encounter order of the stream, as doing so
 416      * would sacrifice the benefit of parallelism.  For any given element, the
 417      * action may be performed at whatever time and in whatever thread the


< prev index next >