StringJoiner: detect or fix delimiter collision?

[Ulf Zibis]

Hi Philip,

Am 27.01.2014 02:12, schrieb Philip Hodges:
> Please please please drop StringJoiner from Java 1.8 before it is too late.
> I have not seen any technical justifications whatsoever so far, just inexplicable enthusiasm.
>
> It is like giving young drivers a faster car with no seat belts.

+++1

I'm also with you with all your arguments against this API.

> I'm really sorry I couldn't carry on arguing the case before August. As a minority, I only have one person's quota of energy. I will try to get some more people to look at it.

You are not alone.
Although I missed the delimiter/escaping problem those days, it was April 18 I posted my different 
concerns about StringJoiner in this list:

<<<<<<<<<<
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 delimiter, 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()

THe current proposed 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?
 >>>>>>>>>>

Am 27.01.2014 18:44, schrieb Mike Duigou:
> The reception we've seen thus far for StringJoiner has been otherwise exclusively enthusiastic and positive.

Where are those people, they don't speak up in this list, seem to don't know about the performance 
issues and the traps which are mentioned here. We don't know how they will deal with the problems in 
practical if they occur in real world.
On the other hand, the "doomsayers" also could refer to others out there which see no win in this API.


-Ulf