RFR: String.join(), StringJoiner additions

[Jim Gish]

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