Spliterator против Stream.Builder

On the other hand I could implement the logic how to advance to the next element around a Stream.Builder and bypass a Spliterator. On every advance I would call accept or add and at the end build. So it looks quite simple.

Да и нет. Это просто является, но я не думаю, что вы понимаете модель использования:

A stream builder has a lifecycle, which starts in a building phase, during which elements can be added, and then transitions to a built phase, after which elements may not be added. The built phase begins when the build() method is called, which creates an ordered Stream whose elements are the elements that were added to the stream builder, in the order they were added.

(Javadocs)

В частности, нет, вы не должны вызывать метод Stream.Builder или acceptadd при любом продвижении потока. Вам необходимо заранее предоставить все объекты для потока в. Затем вы build(), чтобы получить поток, который предоставит все объекты, которые вы добавили ранее. Это аналогично добавлению всех объектов в List и последующему вызову метода List этого stream().

Если это служит вашим целям и вы действительно можете делать это эффективно, тогда отлично! Но если вам нужно генерировать элементы по мере необходимости, с лимитом или без него, Stream.Builder вам не поможет. Spliterator может.

Обратите внимание, что вы можете расширить Spliterators.AbstractSpliterator. Затем остается реализовать только tryAdvance.

Так что сложность реализации Spliterator не выше.

Принципиальное отличие состоит в том, что метод SpliteratortryAdvance вызывается только тогда, когда требуется новый элемент. Напротив, Stream.Builder имеет место хранения, который будет заполнен всеми элементами потока, прежде чем вы сможете получить поток.

Таким образом, Spliterator - лучший выбор для всех видов ленивых вычислений, а также когда у вас есть существующее хранилище, которое вы хотите просмотреть, чтобы избежать копирования данных.

Конструктор - это лучший выбор, когда создание элементов неоднородно, поэтому вы не можете выразить создание элемента по запросу. Подумайте о ситуациях, когда в противном случае вы бы использовали Stream.of(…), но он оказывается негибким.

Например. у вас есть Stream.of(a, b, c, d, e), но теперь оказывается, что c и d необязательны. Итак, решение

Stream.Builder<MyType> builder = Stream.builder();
builder.add(a).add(b);
if (someCondition) builder.add(c).add(d);
builder.add(e).build()
   /* stream operations */

Другими вариантами использования являются этот ответ, где Consumer был необходим для запроса существующего сплитератора и последующей передачи значения обратно в Stream, или этот ответ, где структура без произвольного доступа (иерархия классов) должна передаваться в обратном порядке.