Strings [was Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7]

[Stephen Colebourne]

Joseph D. Darcy wrote:
> Stephen Colebourne wrote:
>> Joe, would you be prepared to sponsor a Strings class, and see join on
>> there instead of String?
> 
> No.
> 
> While I believe a "StringUtils" class would have been appropriate early 
> in the platform's life to host more advanced string manipulation 
> facilities, I don't think adding such a class now is the right design.
> 
> IMO, the join method, whether it is an instance method or a static one, 
> should live in java.lang.String.

This choice effectively means that Java will continue to have no decent 
set of string manipulation code in the JDK IMO. There are many, many 
methods which are coded again and again for manipulating strings. Just 
look at the size of Commons Lang StringUtils, or similar classes elsewhere:

http://commons.apache.org/lang//api/org/apache/commons/lang/StringUtils.html

Any attempt to add this variety of static methods to String will simply 
result in a class containing more static methods than non-static ones.

Of course one can argue that many of these methods could become instance 
methods if added to String itself. Unfortunately, the null-handling 
behaviour of the static method is considered a feature to many (and one 
which instance methods on String wouldn't replicate in the absence of 
Coin's rejected null operators).

(The argument that Strings negates the presence of static methods is one 
I find simplistic. The current static methods on String are factory 
methods - the new ones which might be added have an entirely different 
focus.)

By the way, one advantage of a Strings class is that it could contain a 
new implementation of split - one that doesn't use regex and isn't as 
complex/useless as the current one on String.

But hey, what do I know. I'm obviously not in the slightest bit in tune 
with the thinking around here....

Stephen