Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

[Joseph D. Darcy]

Stephen Colebourne wrote:
> Not wishing to confuse the debate, but perhaps the correct place for
> this is a static Strings class, that parallels Objects.
>
> We all know that there are lots of possible methods for such a class,
> but even if JDK7 had just a few, that would be a good start.
>
> 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.

-Joe

> Stephen
>
>
> 2009/10/23 Kevin Bourrillion <kevinb at google.com>:
>   
>> FYI,
>> While I certainly love my "Joiner" baby, and while y'all have blanket
>> permission to make use of any of our code you want, I think it's entirely
>> appropriate for the JDK to just hit the 80% case with a static method
>> directly on String.
>> (And yes, the fact that split() is an instance method is a false parallel.)
>>
>>
>> On Fri, Oct 23, 2009 at 8:58 AM, Joe Kearney <Joe.Kearney at morganstanley.com>
>> wrote:
>>     
>>> Hi,
>>>
>>> From the peanut gallery, it seems to me that there is a genuine reason to
>>> leave join as a static method (if we're not going after the
>>> google-collections approach of a Joiner class) in that split acts on one
>>> existing String, whereas join creates one from others. On which object would
>>> you call the join method? The separator? I know this was covered on this
>>> list before, but it still strikes me as looking a little wierd.
>>>
>>>       
>>>> ",".join("a", "b", "c")
>>>>         
>>> versus
>>>       
>>>> Joiner.on(",").join("a", "b", "c")
>>>>         
>>> Thanks,
>>> Joe
>>>
>>> 2009/10/23 Mark Reinhold <mr at sun.com>
>>>       
>>>>> Date: Fri, 23 Oct 2009 10:10:35 +0200
>>>>> From: Rémi Forax <forax at univ-mlv.fr>
>>>>>           
>>>>> Le 23/10/2009 03:53, Joe Darcy a écrit :
>>>>>           
>>>>>> Following up on this, what is the exact revised proposal?
>>>>>>
>>>>>> In java.lang.String:
>>>>>>
>>>>>>    public static String join(String separator, Iterable<?> objects);
>>>>>>    public static String join(String separator, Object[] objects);
>>>>>>    public static String join(String separator, Object first, Object...
>>>>>> rest);
>>>>>>
>>>>>> with analogous methods in StringBuffer and StringBuilder return that
>>>>>> type,
>>>>>> respectively, instead of String?
>>>>>>             
>>>>> I don't know. In my opinion, the main problem with join specified using
>>>>> static methods is that split is not currently specified as a static
>>>>> method.  Because join is the dual of split, one could find the usage of
>>>>> static methods weird.
>>>>>           
>>>> I agree.  The join methods should be instance methods, not static
>>>> methods.
>>>>
>>>> - Mark
>>>>         
>>
>> --
>> Kevin Bourrillion @ Google
>> internal:  http://go/javalibraries
>> external: guava-libraries.googlecode.com
>>
>>
>>