Lines Matching defs:stream
31 * int sum = widgets.stream()
38 * as a source for a stream, and then perform a filter-map-reduce on the stream
43 * <p>The key abstraction introduced in this package is <em>stream</em>. The
44 * classes {@link java.util.stream.Stream}, {@link java.util.stream.IntStream},
45 * {@link java.util.stream.LongStream}, and {@link java.util.stream.DoubleStream}
50 * <li>No storage. A stream is not a data structure that stores elements;
54 * <li>Functional in nature. An operation on a stream produces a result,
55 * but does not modify its source. For example, filtering a {@code Stream}
56 * obtained from a collection produces a new {@code Stream} without the
59 * <li>Laziness-seeking. Many stream operations, such as filtering, mapping,
63 * Stream operations are divided into intermediate ({@code Stream}-producing)
70 * <li>Consumable. The elements of a stream are only visited once during
71 * the life of a stream. Like an {@link java.util.Iterator}, a new stream
78 * <li>From a {@link java.util.Collection} via the {@code stream()} and
80 * <li>From an array via {@link java.util.Arrays#stream(Object[])};</li>
81 * <li>From static factory methods on the stream classes, such as
82 * {@link java.util.stream.Stream#of(Object[])},
83 * {@link java.util.stream.IntStream#range(int, int)}
84 * or {@link java.util.stream.Stream#iterate(Object, UnaryOperator)};</li>
88 * <p>Additional stream sources can be provided by third-party libraries using
91 * <h2><a name="StreamOps">Stream operations and pipelines</a></h2>
93 * <p>Stream operations are divided into <em>intermediate</em> and
94 * <em>terminal</em> operations, and are combined to form <em>stream
95 * pipelines</em>. A stream pipeline consists of a source (such as a
98 * {@code Stream.filter} or {@code Stream.map}; and a terminal operation such
99 * as {@code Stream.forEach} or {@code Stream.reduce}.
101 * <p>Intermediate operations return a new stream. They are always
104 * creates a new stream that, when traversed, contains the elements of
105 * the initial stream that match the given predicate. Traversal
109 * <p>Terminal operations, such as {@code Stream.forEach} or
110 * {@code IntStream.sum}, may traverse the stream to produce a result or a
111 * side-effect. After the terminal operation is performed, the stream pipeline
114 * stream. In almost all cases, terminal operations are <em>eager</em>,
129 * more important when the input stream is infinite and not merely large.)
141 * sorting a stream until one has seen all elements of the stream. As a result,
150 * infinite input, it may produce a finite stream as a result. A terminal
154 * stream to terminate normally in finite time.
162 * The stream implementations in the JDK create serial streams unless parallelism is
164 * {@link java.util.Collection#stream} and {@link java.util.Collection#parallelStream},
166 * stream-bearing methods such as {@link java.util.stream.IntStream#range(int, int)}
168 * invoking their {@link java.util.stream.BaseStream#parallel()} method.
180 * example is the creation of the initial stream, using "{@code parallelStream()}"
181 * instead of "{@code stream()}". When the terminal operation is initiated,
182 * the stream pipeline is executed sequentially or in parallel depending on the
183 * orientation of the stream on which it is invoked. Whether a stream will execute in serial or
185 * orientation of a stream can be modified with the
186 * {@link java.util.stream.BaseStream#sequential()} and
187 * {@link java.util.stream.BaseStream#parallel()} operations. When the terminal
188 * operation is initiated, the stream pipeline is executed sequentially or in
189 * parallel depending on the mode of the stream on which it is invoked.
192 * as {@code findAny()}, whether a stream executes sequentially or in parallel
195 * <p>Most stream operations accept parameters that describe user-specified
208 * <em>interference</em> with the data source during the execution of a stream
213 * <em>not modified at all</em> during the execution of the stream pipeline.
216 * Concurrent stream sources are those whose {@code Spliterator} reports the
219 * <p>Accordingly, behavioral parameters in stream pipelines whose source might
220 * not be concurrent should never modify the stream's data source.
223 * modified, the stream's data source. The need for non-interference applies
224 * to all pipelines, not just parallel ones. Unless the stream source is
225 * concurrent, modifying a stream's data source during execution of a stream
228 * For well-behaved stream sources, the source can be modified before the
234 * Stream<String> sl = l.stream();
240 * stream is created from that list. Next the list is modified by adding a third
241 * string: "three". Finally the elements of the stream are collected and joined
246 * <a href="package-summary.html#StreamSources">Low-level stream
251 * Stream pipeline results may be nondeterministic or incorrect if the behavioral
252 * parameters to the stream operations are <em>stateful</em>. A stateful lambda
255 * of the stream pipeline. An example of a stateful lambda is the parameter
260 * stream.parallel().map(e -> { if (seen.add(e)) return 0; else return e; })...
274 * parameters to stream operations entirely; there is usually a way to
275 * restructure the stream pipeline to avoid statefulness.
279 * Side-effects in behavioral parameters to stream operations are, in general,
287 * different operations on the "same" element within the same stream pipeline
290 * <em>result</em> that is consistent with the encounter order of the stream
300 * purposes are usually harmless. A small number of stream operations, such as
304 * <p>As an example of how to transform a stream pipeline that inappropriately
305 * uses side-effects to one that does not, the following code searches a stream
311 * stream.filter(s -> pattern.matcher(s).matches())
325 * stream.filter(s -> pattern.matcher(s).matches())
332 * or not a stream has an encounter order depends on the source and the
333 * intermediate operations. Certain stream sources (such as {@code List} or
336 * an encounter order on an otherwise unordered stream, and others may render an
337 * ordered stream unordered, such as {@link java.util.stream.BaseStream#unordered()}.
341 * <p>If a stream is ordered, most operations are constrained to operate on the
342 * elements in their encounter order; if the source of a stream is a {@code List}
349 * not affect performance, only determinism. If a stream is ordered, repeated
350 * execution of identical stream pipelines on an identical source will produce
361 * In cases where the stream has an encounter order, but the user does not
363 * the stream with {@link java.util.stream.BaseStream#unordered() unordered()} may
365 * However, most stream pipelines, such as the "sum of weight of blocks" example
375 * {@link java.util.stream.Stream#reduce(java.util.function.BinaryOperator) reduce()}
376 * and {@link java.util.stream.Stream#collect(java.util.stream.Collector) collect()},
378 * {@link java.util.stream.IntStream#sum() sum()}, {@link java.util.stream.IntStream#max() max()},
379 * or {@link java.util.stream.IntStream#count() count()}.
391 * "more abstract" -- it operates on the stream as a whole rather than individual
396 * For example, given a stream of numbers for which we want to find the sum, we
399 * int sum = numbers.stream().reduce(0, (x,y) -> x+y);
403 * int sum = numbers.stream().reduce(0, Integer::sum);
463 * int sumOfWeights = widgets.stream()
477 * as it processes the elements in the stream.
479 * <p>If we wanted to take a stream of strings and concatenate them into a
494 * {@link java.util.stream.Stream#collect(Collector) collect()},
513 * stream into an {@code ArrayList}, we could write the obvious sequential
517 * for (T element : stream) {
523 * ArrayList<String> strings = stream.collect(() -> new ArrayList<>(),
530 * List<String> strings = stream.map(Object::toString)
540 * {@link java.util.stream.Collector} to capture all three aspects. The
544 * List<String> strings = stream.map(Object::toString)
549 * composability. The class {@link java.util.stream.Collectors} contains a
552 * collector that computes the sum of the salaries of a stream of
564 * {@link java.util.stream.Collectors#groupingBy(java.util.function.Function, java.util.stream.Collector) groupingBy}:
568 * = employees.stream().collect(Collectors.groupingBy(Employee::getDepartment,
622 * <p>A {@link java.util.stream.Collector} that supports concurrent reduction is
623 * marked with the {@link java.util.stream.Collector.Characteristics#CONCURRENT}
628 * stream being processed. The {@link java.util.stream.Stream#collect(Collector)}
631 * <li>The stream is parallel;</li>
633 * {@link java.util.stream.Collector.Characteristics#CONCURRENT} characteristic,
635 * <li>Either the stream is unordered, or the collector has the
636 * {@link java.util.stream.Collector.Characteristics#UNORDERED} characteristic.
638 * You can ensure the stream is unordered by using the
639 * {@link java.util.stream.BaseStream#unordered()} method. For example:
646 * (where {@link java.util.stream.Collectors#groupingByConcurrent} is the
673 * <h2><a name="StreamSources">Low-level stream construction</a></h2>
675 * So far, all the stream examples have used methods like
676 * {@link java.util.Collection#stream()} or {@link java.util.Arrays#stream(Object[])}
677 * to obtain a stream. How are those stream-bearing methods implemented?
679 * <p>The class {@link java.util.stream.StreamSupport} has a number of
680 * low-level methods for creating a stream, all using some form of a
707 * the spliterator is created and the time the stream pipeline is executed.
708 * Ideally, a spliterator for a stream would report a characteristic of
713 * a spliterator using a {@code Supplier}, and construct a stream via the
715 * {@link java.util.stream.StreamSupport#stream(Supplier, int, boolean) stream()}.
717 * operation of the stream pipeline commences.
720 * interference between mutations of the stream source and execution of stream
724 * operation (provided the behavioral parameters to the stream operations meet
731 package java.util.stream;
