RFR: String.join(), StringJoiner additions
Alan Bateman
Alan.Bateman at oracle.com
Thu Apr 18 11:18:42 UTC 2013
On 17/04/2013 22:49, Jim Gish wrote:
> Here's an update:
> http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/
> <http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7172553/>
>
> Jim
StringJoiner looks much better now, good to see it reduced down to 2
simple constructors.
One thing that I didn't bring up in the previous round is that as all
the parameters are CharSequences, then it probably should be made clear
that the constructors and setEmptyValue method take copies. I'm not
suggesting it would be logical to implement it otherwise but if someone
using StringBuilder or mutable CharSequences implementation needs to be
sure that StringJoiner will do the right thing if the char sequence is
changed subsequently.
In the class description it reads:
"if the {@code emptyValue} parameter is supplied via the ..."
which is a bit confusing because a StringJoiner doesn't have a
"emptyValue parameter". It might be clearer if changed to:
"if a default <i>empty value</i> is specified via the ..."
A minor comment on the wording in the constructors is that "Also" should
probably be dropped from the second sentence.
The 3-arg constructor still specifies that it throws NPE if the
emptyValue is null but there isn't an emptyValue parameter here.
In toString then I assume that you can avoid the +suffix when it is the
empty string (which is going to very common).
You've addressed my previous comment on String.join not specifying how
null behaves so this is clear now - thanks.
Also looks like you've moved the tests and extended the coverage for
nulls - thanks.
So overall I think this is looking much better.
-Alan.
More information about the core-libs-dev
mailing list