Ulf,
My point was simply that none of these classes provide methods that accept
java.lang.Object. IMO, the scenario when we join elements into a String by
calling toString on each element prior to append it -- is the most common
scenario (maybe except for when element is a String itself). That is instead of
doing this:
Iterable<?> whatever = ...
String s = String.join(whatever);
we have to do (at least) something like this:
Iterable<?> whatever = ...
whatever.forEach(w -> builder.append(w.toString());
String s = builder.toString();
or this:
String s = StreamSupport.stream(whatever.spliterator(), false /* or
true */)
.map(Object::toString)
.collect(Collectors.joining(", "));
That is, it's hardly ever a concise one-liner. An 'addAll' method in
j.u.StringJoiner could have saved us, but there isn't one.
(I'm sure there were plenty of engineering reasons not to do things I've
mentioned)
-Pavel
On 11 Aug 2014, at 16:38, Ulf Zibis <ulf.zi...@cosoco.de> wrote:
>
> Am 11.08.2014 um 16:33 schrieb Pavel Rappo:
>> Unfortunately, neither java.util.StringJoiner nor String.join have perfect
>> (but who has?) APIs. So it's up to us to figure out the best way of joining
>> elements.
>
> Maybe remember my thoughts from here:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016172.html
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024761.html
>
> Would it be possible to inherit StringJoiner from StringBuilder in some way?
> Then a mixture of concatanation, StringBuilder and StringJoiner after Javac
> would end up in one StringBuilder instance. We also could profit from
> StringJoiners initial capacity capability.
>
> -Ulf
>
>
