RFR: String.join(), StringJoiner additions

Ulf Zibis Ulf.Zibis at CoSoCo.de
Thu Apr 18 23:38:40 UTC 2013


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




More information about the core-libs-dev mailing list