Версиите с два и три аргумента на reduce, които се опитахте да използвате, не приемат същия тип за accumulator.

Двата аргумента reduce са дефиниран като :

T reduce(T identity,
         BinaryOperator<T> accumulator)

Във вашия случай T е String, така че BinaryOperator<T> трябва да приеме два аргумента String и да върне String. Но му предавате int и String, което води до грешката при компилиране, която сте получили - argument mismatch; int cannot be converted to java.lang.String. Всъщност мисля, че предаването на 0 като стойност за идентичност също е грешно тук, тъй като се очаква низ (T).

Също така имайте предвид, че тази версия на reduce обработва поток от Ts и връща T, така че не можете да я използвате, за да намалите поток от String до int.

Трите аргумента reduce са дефиниран като :

<U> U reduce(U identity,
             BiFunction<U,? super T,U> accumulator,
             BinaryOperator<U> combiner)

Във вашия случай U е цяло число, а T е низ, така че този метод ще намали поток от низ до цяло число.

За акумулатора BiFunction<U,? super T,U> можете да подадете параметри от два различни типа (U и? super T), които във вашия случай са Integer и String. В допълнение, стойността за идентичност U приема цяло число във вашия случай, така че предаването му на 0 е добре.

Друг начин да постигнете това, което искате:

int length = asList("str1", "str2").stream().mapToInt (s -> s.length())
            .reduce(0, (accumulatedInt, len) -> accumulatedInt + len);

Тук типът на потока съвпада с върнатия тип на reduce, така че можете да използвате версията с два параметъра на reduce.

Разбира се, изобщо не е нужно да използвате reduce:

int length = asList("str1", "str2").stream().mapToInt (s -> s.length())
            .sum();

Отговорът на Еран описва разликите между версиите с два и три аргумента на reduce в това, че първата редуцира Stream<T> до T, докато последният редуцира Stream<T> до U. Въпреки това, това всъщност не обяснява необходимостта от допълнителната функция за комбиниране при намаляване на Stream<T> до U.

Един от принципите на проектиране на API за потоци е, че API не трябва да се различава между последователни и паралелни потоци, или казано по друг начин, определен API не трябва да пречи на потока да работи правилно нито последователно, нито паралелно. Ако вашите ламбда имат правилните свойства (асоциативни, неинтерфериращи и т.н.), потокът, изпълняван последователно или паралелно, трябва да даде същите резултати.

Нека първо да разгледаме версията на редукция с два аргумента:

T reduce(I, (T, T) -> T)

Последователното внедряване е лесно. Идентификационната стойност I се "натрупва" с елемента на нулевия поток, за да даде резултат. Този резултат се натрупва с първия елемент на потока, за да даде друг резултат, който от своя страна се натрупва с втория елемент на потока и т.н. След натрупването на последния елемент се връща крайният резултат.

Паралелното внедряване започва с разделяне на потока на сегменти. Всеки сегмент се обработва от собствена нишка по последователния начин, който описах по-горе. Сега, ако имаме N нишки, имаме N междинни резултата. Те трябва да бъдат сведени до един резултат. Тъй като всеки междинен резултат е от тип T и имаме няколко, можем да използваме една и съща акумулираща функция, за да намалим тези N междинни резултата до един резултат.

Сега нека разгледаме хипотетична операция за намаляване на два аргумента, която редуцира Stream<T> до U. На други езици това се нарича "сгъване" или "сгъване- наляво", така че така ще го нарека тук. Имайте предвид, че това не съществува в Java.

U foldLeft(I, (U, T) -> U)

(Обърнете внимание, че стойността на идентичност I е от тип U.)

Последователната версия на foldLeft е точно като последователната версия на reduce с изключение на това, че междинните стойности са от тип U вместо от тип T. Но иначе е същото. (Хипотетична операция foldRight би била подобна, с изключение на това, че операциите ще се извършват отдясно наляво вместо отляво надясно.)

Сега разгледайте паралелната версия на foldLeft. Нека започнем, като разделим потока на сегменти. След това можем да накараме всяка от N нишките да намали стойностите T в своя сегмент в N междинни стойности от тип U. Сега какво? Как да стигнем от N стойности от тип U до един резултат от тип U?

Това, което липсва, е друга функция, която комбинира множеството междинни резултати от тип U в един резултат от тип U. Ако имаме функция, която комбинира две U стойности в една, това е достатъчно, за да намали произволен брой стойности до едно -- точно като първоначалното намаление по-горе. По този начин операцията за намаляване, която дава резултат от различен тип, се нуждае от две функции:

U reduce(I, (U, T) -> U, (U, U) -> U)

Или, използвайки синтаксиса на Java:

<U> U reduce(U identity, BiFunction<U,? super T,U> accumulator, BinaryOperator<U> combiner)

В обобщение, за да направим паралелно редуциране до различен тип резултат, имаме нужда от две функции: една, която натрупва T елементи до междинни U стойности, и втора, която комбинира междинните U стойности в един U резултат. Ако не превключваме типовете, се оказва, че акумулаторната функция е същата като комбиниращата функция. Ето защо редуцирането до същия тип има само акумулираща функция, а редуцирането до различен тип изисква отделни акумулаторни и комбиниращи функции.

И накрая, Java не предоставя foldLeft и foldRight операции, защото те предполагат конкретно подреждане на операциите, което по своята същност е последователно. Това се сблъсква с посочения по-горе принцип на проектиране за предоставяне на API, които поддържат еднакво последователна и паралелна работа.

Тъй като харесвам драскулки и стрелки за изясняване на концепции... да започваме!

От низ към низ (последователен поток)

Да предположим, че имате 4 низа: вашата цел е да свържете такива низове в един. По принцип започвате с тип и завършвате със същия тип.

Можете да постигнете това с

String res = Arrays.asList("one", "two","three","four")
        .stream()
        .reduce("",
                (accumulatedStr, str) -> accumulatedStr + str);  //accumulator

и това ви помага да визуализирате какво се случва:

Акумулаторната функция преобразува, стъпка по стъпка, елементите във вашия (червен) поток до крайната намалена (зелена) стойност. Функцията акумулатор просто трансформира String обект в друг String.

От низ към int (паралелен поток)

Да предположим, че имате същите 4 низа: вашата нова цел е да сумирате дължините им и искате да паралелизирате потока си.

Това, от което се нуждаете, е нещо подобно:

int length = Arrays.asList("one", "two","three","four")
        .parallelStream()
        .reduce(0,
                (accumulatedInt, str) -> accumulatedInt + str.length(),                 //accumulator
                (accumulatedInt, accumulatedInt2) -> accumulatedInt + accumulatedInt2); //combiner

и това е схема на случващото се

Тук акумулаторната функция (a BiFunction) ви позволява да трансформирате вашите String данни в int данни. Тъй като потокът е паралелен, той е разделен на две (червени) части, всяка от които се разработва независимо една от друга и дава също толкова частични (оранжеви) резултати. Дефинирането на комбинатор е необходимо, за да се осигури правило за обединяване на частични int резултати в крайния (зелен) int.

От низ към int (последователен поток)

Ами ако не искате да паралелизирате потока си? Е, така или иначе трябва да се предостави комбинатор, но той никога няма да бъде извикан, като се има предвид, че няма да се получат частични резултати.

Няма версия за намаляване, която приема два различни типа без комбинатор, тъй като не може да се изпълнява паралелно (не знам защо това е изискване). Фактът, че акумулатор трябва да е асоциативен, прави този интерфейс почти безполезен, тъй като:

list.stream().reduce(identity,
                     accumulator,
                     combiner);

Дава същите резултати като:

list.stream().map(i -> accumulator(identity, i))
             .reduce(identity,
                     combiner);