< prev index next >

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

Print this page




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


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




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


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


< prev index next >