RFR [8054221] StringJoiner imlementation optimization

[roger riggs]

Hi,

Don't get too carried away on adding convience methods,  last year when 
StringJoiner
was proposed, there was quite a bit of tension between enough and too much.
Don't add to the size and maintenance of the JDK without a clear use case
and knowledge that the APIs will be used frequently.

Roger

On 8/5/2014 7:55 AM, Ivan Gerasimov wrote:
> Thanks you Martin!
>
> On 05.08.2014 9:52, Martin Buchholz wrote:
>>
>> I'm truly unsure whether it's worth optimizing for size < 2.
>
> With saving results of compaction in merge, this case will become a 
> little more common.
> This way X.merge(Y); Y.toString(); can work a bit faster.
>
>> But if we do that, I think we should optimize size == 0 as well, thus:
>>
>> if (addLen == 0 && size <= 1)
>>  return (size == 0) ? "" : elts[0];
> Yes, done.
>
>> ---
>>   240         if (other == this) {
>>
>> I doubt that optimizing specially for a self-merge is worthwhile.
>
> You're probably correct, it's not worth coding that.
> I just was upset that combining with itself doesn't work as well as in 
> other cases, that's why I implemented it.
> I'll remove it.
>
> Here's the updated webrev:
> http://cr.openjdk.java.net/~igerasim/8054221/1/webrev/
>
>> When you're thinking of doing that, you probably really want
>> Strings.repeat(String, int copies)
>> https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/base/Strings.java?r=5cc3b0b33392b02ff95a4ce5f291c439b5b1406e#154 
>>
>>
>> I suggest adding repeat to String!
>>
>
> Yes, it would be a useful addition.
> In addition, there might be overloads with a delimiter, prefix and 
> suffix :-)
>
> Sincerely yours,
> Ivan
>