StringJoiner: detect or fix delimiter collision?

[Philip Hodges]

Are we really going ahead with an implementation that:
- checks even string literal parameters for null
- does it again when String.join calls StringJoiner
- makes defensive copies of just some of the arguments
- creates a StringBuilder with only the default capacity

People would be better off taking a look at
AbstractCollection.toString or Arrays.toString and then,
if they haven't already, roll their own, enhanced with a
StringBuilder capacity, and without all the defensive baggage.

To come back to my original point about why it is a toy interface:

The only worthwhile value that StringJoiner can possibly add is a way
to force programmers to make a conscious decision to waive checking
to see if the separator (or prefix or suffix) can or does occur
in any of the elements, and to apply an escaper/quoter if needed.

Please add some failing round trip unit tests with split to
help raise awareness of the issue of delimiter collision.

The original String elements cannot be extracted from the result
if there are no elements, one empty element, any null elements,
or if the separator occurs in any of the elements.

Please add a test of String.join with delimiter and no varargs elements,
and another test with one null varargs element. I don't feel comfortable
with a signature that does not clearly separate the delimiter from the elements.

Please put an example with escaping in the javadoc.

You might want to change that ridiculous "Java-is-cool" example.
Of course there are a lot of cool things about Java, and even
String.join cannot compete with acknowledged uncool features
such as Calendar, mutable Dates and unthreadsafe Formatters.
Nevertheless, the example text risks becoming ironic.

Please take a proper critical look at whether there is any
genuine need to dump this half-baked toy into everyone's jdk.
There are some good ideas in Java 8. This is not one of them.

It will soon be starring behind the scenes in CERT advisories.
Once people start using it, even if you do accept and try to fix the
flaws, you will then have two versions in circulation for many years.
And then I will be able to say "I told you so", instead of
"thank goodness we woke up and stopped it so we could get it right first time".

Why is there such a bandwagon rolling for this "convenience" feature?

It is not "long overdue".
Arrays.toString and AbstractCollection.toString have been there for years.
We already have joiners in apache commons and guava.
At first I thought they were cool. Then I tried to use them in anger.
And was forced to roll my own. That can't be right.

A more elaborate offically blessed feature that
only does half the job is worse than useless.
Without the extra complex ability to detect or avoid collisions
it is neither "nice", nor a "Good Thing".

Phil

http://www.techempower.com/blog/2013/03/26/everything-about-java-8/

"StringJoiner and String.join(...) are long, long overdue. They are so long overdue that the vast majority of Java 
developers likely have already written or have found utilities for joining strings, but it is nice for the JDK to 
finally provide this itself. Everyone has encountered situations where joining strings is required, and it is a Good 
Thing™ that we can now express that through a standard API that every Java developer (eventually) will know. "


On 2013-07-23 22:09, Mike Duigou wrote:
>
> On Jul 23 2013, at 12:43 , ph wrote:
>
>> didn't see delimiter collision mentioned anywhere - are you really offering
>> an interface that only joins a list of entries without escaping or quoting
>> or even checking for separators (or escape or quote sequences) that might
>> occur in the entries?
>
> Correct. StringJoiner makes no effort to address escaping/quoting.
 > Doing so would add a lot of complexity that would not
 > useful interesting to most users and probably still wouldn't satisfy everyone.

> If you wish some form of escaping or quoting you can pre-processed entries however you like before joining them.
>
> Mike
>