Strings [was Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7]
scolebourne at joda.org
Mon Oct 26 21:38:11 UTC 2009
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?
> 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:
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
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....
More information about the core-libs-dev