RFR: String.join(), StringJoiner additions

[Henry Jen]

Sorry I am not receiving emails from core-lib-dev earlier.

What I did was to remove things we considered not absolutely required, which left us only a StringJoiner class and two String.join methods.

StringJoiner was intended to be used with Stream as a collector, thus prefix, and suffix is desired like Collection.toString().

Cheers,
Henry


On Apr 19, 2013, at 9:54 AM, Jim Gish <jim.gish at oracle.com> wrote:

> Hi Henry,  Can you please comment on the simplifications you did ?
> 
> Thanks,
>    Jim
> 
> On 04/18/2013 07:38 PM, Ulf Zibis wrote:
>> Am 18.04.2013 19:37, schrieb Jim Gish:
>>> 
>>> On 04/18/2013 08:49 AM, Ulf Zibis wrote:
>>>> 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);
>>> I started off with something similar, but it was stripped out when Henry did the performance improvements.
>> 
>> Hm, I have no idea, how above suggestions should prevent performance improvements. Can you help me?
>> 
>>> Given that most people feel that this is going to be put to heavy-weight usage, it doesn't seem to merit too much emphasis on performance or complicating the implementation at this point.
>> 
>> Your implementation has
>> 1 class with 7 methods
>> 2 additional methods in String
>> To cover the same functionality, above approach basically only needs 2 additional methods in StringBuilder, has better performance, so what is complicated on that?
>> 
>> @Martin: What is your opinion?
>> 
>> Thanks,
>> 
>> -Ulf
>> 
>> 
>>>> 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
>> 
> 
> -- 
> 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
>