The current Seq.zip() method "inner zips" two streams, such that the size of the resulting stream is the minimum of the size of each zipped stream.

Sometimes, it is useful, however, to fully zip all streams, providing Optional values (or nulls) once the shorter stream is depleted. Example:

// ((1, "A"), (2, "B"))
Seq.of(1, 2, 3).zip(Seq.of("A", "B"));

// ((1, "A"), (2, "B"), (3, null))
Seq.of(1, 2, 3).leftOuterZip(Seq.of("A", "B"));

// ((1, "A"), (2, "B"), (null, "C"))
Seq.of(1, 2).rightOuterZip(Seq.of("A", "B", "C"));

I'm looking for a way to take a Seq<T> and transform it to a Seq<List<T>> for batch processing while keeping lazy evaluation. (I am streaming and processing large files from S3 then pushing them back to S3)

I found the following and have two concerns. http://stackoverflow.com/a/30662609

1. Note that this solution unnecessarily stores the whole input stream to the intermediate Map (unlike, for example, Ben Manes solution) Is this accurate?
2. I believe the groupBy would exhaust the entire stream. In my case the file may not fit in memory so this would not work if that is the case.

Would the above be worth creating a helper for? Or would it be worth making something similar to Guavas Iterables.partition

CompletableFutures API seems a bit off. It would be nice to have an implementation that remembered its Executor and used it by default for all async operations instead of the common pool. Also a shorter name might be nice.

Simplified possible implementation.

// Promise might not be a great name
public class Promise<T> implements Future<T>, CompletionStage<T> {
    private final CompletableFuture<T> future;
    private final Executor defaultExecutor;

    // This could be private and use static methods the same way CompletableFuture does.
    public Promise(CompletableFuture<T> future, Executor defaultExecutor) {
        this.future = future;
        this.defaultExecutor = defaultExecutor;
    }

    @Override
    public <U> Promise<U> thenApply(Function<? super T, ? extends U> fn) {
        return new Promise<>(future.thenApply(fn), defaultExecutor);
    }

    @Override
    public <U> Promise<U> thenApplyAsync(Function<? super T, ? extends U> fn) {
        return new Promise<>(future.thenApplyAsync(fn), defaultExecutor);
    }

    @Override
    public <U> Promise<U> thenApplyAsync(Function<? super T, ? extends U> fn, Executor executor) {
        return new Promise<>(future.thenApplyAsync(fn), executor);
    }

    public T join() {
        return future.join();
    }

    public CompletableFuture<T> getCompletableFuture() {
        return future;
    }

}

This would allow us to use CompletableFuture under the hood and get any future improvements from it. It would gain the benefit of remembering the last Executor used.

#296 I have two of the implementations working and they should be truly lazy.

• [x] chunked(long chunkSize)
• [x] chunked(Predicate predicate)
• [ ] chunked(Predicate predicate, boolean excludeDelimiter) ?
• [ ] chunkedWithIndex(BiPredicate<T, Long> biPredicate)

I'm not sure happy with how the code turned out. The two iterators are a little dependent on each other. Maybe a better approach would be to make a more top level peeking iterator instead of hacking it like I did.

Does anything like the following currently exist in jOOL, or would there be any appetite for adding something like it? I created my own, as I couldn't find anything.

public class Tuple2Lambdas {

    public static <A, B> Predicate<Tuple2<A, B>> predicate(BiPredicate<A, B> predicate) {

        return (tuple) -> predicate.test(tuple.v1, tuple.v2);

    }

    public static <A, B, R> Function<Tuple2<A, B>, R> function(BiFunction<A, B, R> function) {

        return (tuple) -> function.apply(tuple.v1, tuple.v2);

    }

    public static <A, B> Consumer<Tuple2<A, B>> consumer(BiConsumer<A, B> consumer) {

        return (tuple) -> consumer.accept(tuple.v1, tuple.v2);

    }

}

This allows the following:

        Seq.seq(tuple2List)
            .filter(predicate(this::validHit))
            .map(function(this::getDisplayMatch))
            .forEach(consumer(this::processResult));

or:

        Seq.seq(tuple2List)
            .filter(predicate((hit, property) -> hit.getId().equals("blah")))
            .map(function((hit, property) -> tuple(hit.explanation(), property.getId())))

rather than the more long winded:

        Seq.seq(tuple2List)
            .filter(tuple -> validHit(tuple.v1, tuple.v2))
            .map(tuple -> getDisplayMatch(tuple.v1, tuple.v2))
            .forEach(tuple -> processResult(tuple.v1, tuple.v2));

or more opaque:

        Seq.seq(tuple2List)
            .filter((tuple) -> tuple.v2.getId().equals("blah"))
            .map((tuple) -> tuple(tuple.v1.explanation(), tuple.v2.getId())

Most times when I've rolled my own solutions to Java's lambda limitations I then find jOOL has beaten me to it, but I couldn't find anything in this case.

Fixed #151

All of the functions follows the link of https://docs.oracle.com/database/121/SQLRF/functions165.htm#SQLRF00696. The formula of calculations are standard formulas. There are totally 9 functions implemented, as mentioned in the link.

As for the test cases, there includes the empty Seq test, and the test with self defined class and Tuple2. All the tests have passed with no conflicts with other tests.

Seq.lazy(Supplier<? extends Stream<T>>) would take a Stream supplier and turn it (lazily) into a Seq.

If we wanted to support other types (e.g. IntStream, Iterable<T>, Optional<T>, T) we'd have to use different names for each method because of Supplier's type erasure, e.g. lazySeq, lazyIntSeq, lazyIterable, lazyOptional, lazyValue (they would generally correspond to what can be non-lazily obtained by Seq.of and Seq.seq).

For me, however, simple Seq.lazy() would be quite enough because it's just a matter of calling Seq.of or Seq.seq inside the lazy Supplier body.

As per: #87

Added curry() methods to all Functions, allowing them to be partially applied and return a new function that accepts the remaining arguments.

This is my second attempt to propose Seq.lazy() (see #302 for details).

Here, I propose it together with the reimplementations of the following methods mentioned in #195 (in order to demonstrate the real usefulness of Seq.lazy):

• shuffle() (provided simpler implementation)
• reverse()
• removeAll()
• retainAll()
• window() (this has to be adapted by @lukaseder in jOOQ-tools)

I did not reimplement the following methods (although they eagerly call iterator() or spliterator(), they do not try to iterate it immediately so they don't seem to be problematic in practice):

• zip(), zipAll()
• SeqUtils.transform()
• grouped
• partition (returns Tuple - could not use Seq.lazy)
• duplicate() (returns Tuple - in this particular case I'd implement it using SeqBuffer proposed in #305)

Reimplementation of the remaining methods mentioned in #195 (i.e. all kinds of joins) was proposed in #305.

Hi Lukas,

I'm not convinced about the java.util.stream.Stream.of() API. There are

• Stream.of(T t) respectively Seq.of(T t)
• Stream.of(T... values) respectively Seq.of(T... values)

which does not allow us to create a Stream/Seq of an Array, i.e.

• Seq.of(new String[] { "hello" }) is a Seq<String> instead of a Seq<String[]>

Workaround:

• Seq.of(new String[][]{{ "" }}), which is ugly

Just want to hear your opinion about the practical value of having a special API for a singleton Array Seq.

And also: What is the use case for a Stream.of(T t). If there would be only a Stream.of(T... values) we could also call Stream.of(t)!? Looking at the implementation of java.util.stream.Stream.of(T t) I see a difference, but from the API perspective I don't see the point.

- Daniel

I've been using this construction a lot lately:

Seq<SomeObject> seq = ...;
Map<Integer, SomeObject> objectMap = seq.toMap(SomeObject::getId, Function.identity());

And I've think this sugar-addition would be nice for jOOL.

interface Collectable<T> {
    /**
     * Collect the collectable into a {@link Map} with the given keys
     * and the self element as value.
     */
    <K> Map<K, T> toIdentityMap(Function<? super T, ? extends K> keyMapper);
}

I can provide a PR. Alternative names to toIdentityMap are very welcome. ;-)

I re-propose attention to an old issue that has not yet been fully solved: #214

Currently jOOL offers:

Function<Tuple[N]<T...>, R> Tuple.function(Function[N]<T..., R>)
Consumer<Tuple[N]<T...>>    Tuple.consumer(Consumer[N]<T...>)

But it misses:

Predicate<Tuple[N]<T...>>   Tuple.predicate(Predicate[N]<T...>)

In order to beautify stream processing like that:

Seq.of(tuple("marco", 24), tuple("luigi", 16), tuple("maria", 18))
   .filter(Tuple.predicate((name, age) -> age > 17))
   .map(Tuple.function((name, age) -> tuple("Sir / Madame " + name, age)))
   .forEach(Tuple.consumer((name, age) -> process(options, name, age)));

Expected behavior and actual behavior:

Re: Median definition. See code examples below.

The Agg.percentileBy method incorrectly assumes that index rounding is enough, but isn't when the the (size * percentile) still has an effectively non-zero factional part, and the floor indexed value and the next value are not equal.

I appreciate that not all Comparable types can be, or easily, added and divided, so I suggest that a modified percentile method, and median method, be added, accepting a type specific function, with parameters for the floor indexed value, the next indexed value and the fractional part of the index, to allow returning a more correct value. The function would only need to be called when the index has an effectively non-zero fractional part and the relevant indexed values are different. Any such new functionally should also exposed anywhere else the existing median and percentile* methods are also exposed e.g. Window.

Steps to reproduce the problem:

e.g. for median

Seq.of(1d,2d,3d,4d,5d,6d,7d).median().ifPresent(System.out::println);

prints 4.0, which is correct, because the exact middle value is 4.0,

Seq.of(1d,2d,3d,4d,5d,6d,7d,8d).median().ifPresent(System.out::println);

prints 4.0 which is apparently incorrect, because the middle values are 4 and 5, so should print (4 + 5) / 2 = 4.5

Versions:

• jOOλ: 0.9.14
• Java: 15

Expected behavior and actual behavior:

I'm building a Seq that contains limit() and window() terms and I'm seeing some surprising behavior:

• If the limit() comes after the window() it appears that the iterator that the Seq is based on gets completely drained even though the stream terminates as expected after the number of items specified in the limit() are processed.
• If the limit() comes before the window() the iterator is not drained. (The stream also terminates as expected.)

In my real scenario, the iterator that the Seq is based on is an iterator on top of a DB cursor and the limit() comes after the window(). I really need the behavior to not be that the code tries to drain this iterator--i.e., read a ton of rows from the DB.

Is this a bug or just the way things work?

Steps to reproduce the problem:

I've attached a simple program that exhibits the behavior.

Versions:

• jOOλ: 0.9.12
• Java: 1.8

Currently, when using the Range type, bounds are swapped by default, if they are not in order. This can be convenient occasionally, but incorrect in other cases. With the suggestion of supporting (partially) unbounded ranges (#350), swapping may become wrong.

We should introduce new API that allows for swapping explicitly (akin to SQL's BETWEEN SYMMETRIC) and stop swapping implicitly.

This is an incompatible change. We might not actually implement it.

The current Tuple.collectors() implementation is a canonical one, where collectors are completely independent of one another. It would be better if they could share state in case they're related. For example, when calculating a set of percentiles:

var percentiles =
Stream.of(1, 2, 3, 4, 10, 9, 3, 3).collect(
  Tuple.collectors(
    Agg.<Integer>percentile(0.0),
    Agg.<Integer>percentile(0.25),
    Agg.<Integer>percentile(0.5),
    Agg.<Integer>percentile(0.75),
    Agg.<Integer>percentile(1.0)
  )
);
 
System.out.println(percentiles);

It would be great if the 5 collectors could somehow share their internal state, which is a sorted list of all values in the stream. Executing 1 sort instead of 5 is definitely preferrable.

This can be implemented in 2 ways:

• Optimising for specific collector usage
• Optimising this in general