RFR: String.join(), StringJoiner additions

[Ulf Zibis]

Hi,

I'm wondering, that StringJoiner has some logic for pre/suffix, but nothing to loop the elements 
themselves :-(

To me, StringJoiner is a useless complicated box around StringBuilder, and imagine, someone needs 
thread-safety.
It also slows down performance, as it needs additional instances and additional class to be loaded 
(critical at VM startup).

Instead please add to StringBuilder and StringBuffer:
      append(CharSequence... elements);
      append(char delimiter, CharSequence... elements);
append(char delimiter, Iterable<? extends CharSequence> elements);
cut(int len);    // removes len chars at the end of the sequence
optional:
append(CharSequence delimiter, CharSequence... elements);
append(CharSequence delimiter, Iterable<? extends CharSequence> elements);

For performance reasons, append should always append the trailing delimeter, which could be cut at 
the end.

It's questionable, if class string needs a static (=no relation to an existing string in contrast to 
non-static split()) join method, as it seduces to
         "[" + String.join(...) + "]"
which needs some effort from javac side to optimize to a single StringBuilder task.
IMO we better had StringBuilder.join(...), so javac could easily optimize to:
     new StringBuilder().append('[').append(',', someStrings).cut(1).append(']').toString()

-Ulf


Am 18.04.2013 00:07, schrieb Martin Buchholz:
> I'm still wondering about whether a joiner utility should support a prefix
> and suffix.  The obvious uses for this are collection class toString
> methods, but we already know that we can and should implement those with a
> single precise char[] construction, so should not use StringJoiner, or at
> least not this StringJoiner implementation.  And if we're just talking
> about pure convenience, it's hard to beat
>
> "[" + String.join(...) + "]"
>
>
> On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish <jim.gish at oracle.com> wrote:
>
>> Here's an update: http://cr.openjdk.java.net/~**
>> jgish/Bugs-5015163-7172553/<http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/><
>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7172553/<http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7172553/>
>> Jim
>>
>>
>> On 04/17/2013 03:15 PM, Mike Duigou wrote:
>>
>>> String::
>>>
>>> line 1253: This should use {@code } rather than <code></code>. I think
>>> regular spaces are OK as well.   seems inappropriate.
>>>
>>> lines 2425/2467: elements may not be null either.
>>>
>>> I can tell you (or maybe it's just me) are itching to change :
>>>
>>> for (CharSequence cs: elements) {
>>> 2477             joiner.add(cs);
>>> 2478         }
>>>
>>> to:
>>>
>>> elements.forEach(joiner::add);
>>>
>>> StringJoiner::
>>>
>>> - <blockquote> isn't needed around <pre> as it's already a <div> you
>>> probably mean to do
>>>
>>> <pre> {@code
>>> ...
>>> }</pre>
>>>
>>> for code samples.
>>>
>>> - It would be nice if the empty output generation in three arg
>>> constructor could be suppressed unless needed. Perhaps a special (not null
>>> please!) sentinel value?
>>>
>>> - Four arg constructor doesn't include emptyOutput in @throws NPE
>>>
>>>
>>> On Apr 11 2013, at 15:33 , Jim Gish wrote:
>>>
>>>   Please review http://cr.openjdk.java.net/~**jgish/Bugs-5015163-7175206-*
>>>> *7172553/<http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/><
>>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7175206-**7172553/<http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7175206-7172553/>
>>>> These are changes that we made in lambda that we're now bringing into
>>>> JDK8.
>>>>
>>>> I've made a couple of additions - making StringJoiner final and adding a
>>>> couple of constructors to set the emptyOutput chars.
>>>>
>>>> Thanks,
>>>>     Jim
>>>>
>>>> --
>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>>> Oracle Java Platform Group | Core Libraries Team
>>>> 35 Network Drive
>>>> Burlington, MA 01803
>>>> jim.gish at oracle.com
>>>>
>>>>
>> --
>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>> Oracle Java Platform Group | Core Libraries Team
>> 35 Network Drive
>> Burlington, MA 01803
>> jim.gish at oracle.com
>>
>>