I end up needing this quite often when dealing with async stuff. Here's mine:

private static <T> Collector<T, ?, Stream<T>> force() {
    return Collectors.collectingAndThen(Collectors.toList(), List::stream);
}

So you can say something like:

Set<String> rappers = loadRappers();
Set<String> causesOfDeath = rappers.stream()
    .map(causeOfDeathService::findCauseOfDeathAsync)
    .collect(force())
    .flatMap(swallowingExceptions(Future::get))
    .collect(Collectors.toSet());

The point being that without the force, this pipeline will send one request, then wait for it to come back, then send another, etc, whereas with the force, the portion of the pipeline above the force will run for everything before the portion after.

Things i've run into which i need:

• mapEntryToLong, eg with (k, v) -> ((long) k.hashCode()) << 32 + v.hashCode(), and potentially the int and double versions, for parity with Stream

• mappingEntriesToValues, eg with (t, e) -> e + " happened at " + t

Do those make sense? I will try for a PR if so.

I needed this on another project, I thought it could be of interest for you? I could not find (although it did not search that much) stream join implementation that is not using something like a flat map.

Joining stream that are exposing the sorted characteristic can use a sort merge join algorithm.

When using the iterator function on the resulting stream the StreamUtils.aggregate() method returns, the Iterator adapter fails.

This happens because the tryAdvance of the AggregatingSpliterator calls the Consumer only when the isSameSlide() method returns. This breaks the contract of the tryAdvance() method that must call action for every calls.

    @Override
    public boolean tryAdvance(Consumer<? super List<I>> action) {
        boolean hadElements = source.tryAdvance(curElem -> {
                if(!isSameSlide(curElem)) {
                    action.accept(currentSlide);
                    currentSlide = new ArrayList<>();
                }
                currentSlide.add(curElem);
            }
        );
        if (!hadElements && !currentSlide.isEmpty()) {
            action.accept(currentSlide);
            currentSlide = new ArrayList<>();
        }
        return hadElements;
    }

The hasNext() method of the adapter for the iterator() function returns true only if the action is called.

    /**
     * Creates an {@code Iterator} from a {@code Spliterator}.
     *
     * <p>Traversal of elements should be accomplished through the iterator.
     * The behaviour of traversal is undefined if the spliterator is operated
     * after the iterator is returned.
     *
     * @param <T> Type of elements
     * @param spliterator The spliterator
     * @return An iterator
     * @throws NullPointerException if the given spliterator is {@code null}
     */
    public static<T> Iterator<T> iterator(Spliterator<? extends T> spliterator) {
        Objects.requireNonNull(spliterator);
        class Adapter implements Iterator<T>, Consumer<T> {
            boolean valueReady = false;
            T nextElement;

            @Override
            public void accept(T t) {
                valueReady = true;
                nextElement = t;
            }

            @Override
            public boolean hasNext() {
                if (!valueReady)
                    spliterator.tryAdvance(this);
                return valueReady;
            }

            @Override
            public T next() {
                if (!valueReady && !hasNext())
                    throw new NoSuchElementException();
                else {
                    valueReady = false;
                    return nextElement;
                }
            }
        }

        return new Adapter();
    }

• Moved selectors and function to their respective package (see issue #14)
• Added checks to constructor parameters for the spliterators
• Make all the spliterator classes final

The javadoc in StreamUtils is pretty good, but the README's documentation is outdated. There should be a way to keep the docs automatically up to date.

Perhaps the outdated documentation could be removed and a link provided to the javadocs or maybe there is a way to generate README from the javadocs.

Implementation via Spliterators would be faster because 1) spliterator API suits for taking/dropping/zipping better, 2) Iterators are anyway converted to spliterators inside the Streams framework.

The documentation of windowed says that the last window is guaranteed to be of the desired size (possible data loss). Passing in a stream with less than window size elements however results in a window smaller than the desired size.

In the example below it would be nice if one doesn't get a window of size 1, but rather no window at all.

IntStream stream = IntStream.of(1);
List<Integer> sumOfPairs = StreamUtils.windowed(stream.boxed(), 2)
                .map(x -> x.get(0) + x.get(1))
                .collect(Collectors.toList());

I just came across a situation where I needed an inclusive version of takeWhile. This operator would take elements from a stream until but including the first element that does not match the given predicate.

It would be great if we could add takeWhileInclusive to the protonpack, along with inclusive versions of other operators like takeUntil, skipWhile, etc.

StreamUtils.windowed(Stream.of(1,2,3), 2, 2)

• [1,2] only

It would be good to have an option to make the last window available (to avoid data lost). Something like StreamUtils.windowed(Stream.of(1,2,3), 2, 2, true)

• [1,2], [3]

From what I saw this is due to the following block in WindowedSpliterator

        if (next.size() != windowSize) {
            next.clear();
        }

Thanks

I began making my own StreamUtils then found this library. Looking through the StreamUtils I couldn't find the null/Optional.empty way to get a stream.

Example: http://stackoverflow.com/a/29406604/970308

Does that already exist or could it be added? I'm happy to send a PR.

Hi,

This is a helpful shortcut to filter entries without dealing with the extraction of key or value.

I know it adds to the maintenance but it is a common pattern I had everywhere.

Per tests:

mapStream.filterKeys(predicate).collect();
...
mapStream.filterValues(predicate).collect();

Thanks

Maybe i am using it wrongly, but I guess it should be useful to transform values Indexed<T> => Indexed<U> in a more natural way.

I have a sequential Stream<T>, I deeply care about the positions of the elements, so the first thing I do with them is zipWIthIndex, so that I can have a Stream<Indexed<T>>. Then, I would like to work with U values. If I want to keep the indexes, I would do something like this:

// Stream<T> myOriginalStream
// Function<T, U> mapper
StreamUtils.zipWithIndex(myOriginalStream)
  .map(indexed -> Indexed.index(indexed.getIndex(), mapper.apply(indexed.getValue())))

which is cumbersome. The same result could be done a little more naturally:

// Stream<T> myOriginalStream
// Function<T, U> mapper

// first option

StreamUtils.zipWithIndex(myOriginalStream)
                .map(Indexed::index)
                .map(i -> i.mapping(mapper))
                // do something
               ;

// second option

StreamUtils.zipWithIndex(myOriginalStream)
                .map(Indexed::index)
                .map(Indexed.mapping(mapper))
                // do something

This could be achieved adding the following methods in Indexed:

public <U> Indexed<U> map(Function<T, U> mapper) {
    return Indexed.index(index, mapper.apply(value));
}

// for the second option
public static <T, U> Function<Indexed<T>, Indexed<U>> mapping(Function<T, U> mapper) {
    return i -> i.map(mapper);
}

A way to verify that this works fine would be as follow (based on ZipTest.zips_a_stream_with_index):

    @Test public void
    zips_a_stream_with_index_and_map() {
        Stream<String> source = Stream.of("Foo", "Bar", "Baz");

        List<Indexed<String>> zipped = StreamUtils.zipWithIndex(source)
                .map(Indexed.mapping(String::toLowerCase))
                .collect(Collectors.toList());

        assertThat(zipped, contains(
                Indexed.index(0, "foo"),
                Indexed.index(1, "bar"),
                Indexed.index(2, "baz")));
    }

Bumps junit from 4.13 to 4.13.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Method StreamUtil.interleaving() seems to be broken in v1.14. I keep getting this exception:

java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;
	at com.codepoetics.protonpack.InterleavingSpliterator.tryAdvance(InterleavingSpliterator.java:48)
	at java.util.Spliterator.forEachRemaining(Spliterator.java:326)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
	at com.swheel.core.StreamUtilsTest.interleaving(StreamUtilsTest.java:40)

The following unit test reproduces this:

public class StreamUtilsTest {

    String cn11 = "11";
    String cn12 = "12";
    String cn21 = "21";
    String cn22 = "22";

    List<String> list1 = Arrays.asList(cn11, cn12);
    List<String> list2 = Arrays.asList(cn21, cn22);

    @Test
    public void interleaving() {
        AtomicLong evenOdd = new AtomicLong();
        Function<String[], Integer> alternating = cns -> {
            assert cns.length == 2;
            if (cns[0] == null) return 1;
            if (cns[1] == null) return 0;
            if (evenOdd.getAndIncrement() % 2 == 0) {
                return 0;
            } else {
                return 1;
            }
        };

        List<String> res =
            StreamUtils.interleave(alternating, Arrays.asList(list1.stream(), list2.stream()))
                    .collect(Collectors.toList());

        Assert.assertEquals(Arrays.asList(cn11, cn21, cn12, cn22), res);
    }
}

I get no compile errors for this test, but the strange ClassClast at runtime.