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

[David Holmes]

Joseph D. Darcy wrote:
> Neal Gafter wrote:
>> You can hardly add any methods to Object, event static methods, 
>> without breaking compatibility, because they get added to every the 
>> overload set if the name is used for methods in existing code.
> 
> Indeed, which is why these methods were added in a new class to prevent 
> unwanted changes to the meaning of source code.

Ah yes I hadn't considered that. A static method in Object would be found 
ahead of an imported method.

Pity - it would have been somewhat more consistent. Though I guess now only 
String is "inconsistent" with regard to the 's' class convention (not that 
I'd advocate changing that.)

Thanks,
David

> -Joe
> 
>>
>> On Mon, Oct 26, 2009 at 9:29 AM, David Holmes <David.Holmes at sun.com 
>> <mailto:David.Holmes at sun.com>> wrote:
>>
>>     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.
>>
>>
>>     +1.
>>
>>     It was necessary to introduce Arrays and Collections for utility
>>     methods because there was no place else to locate the static
>>     methods. But for String these should simply be static String methods.
>>
>>     But that also means I'd prefer to see additional static methods in
>>     Object, rather than the added Objects class.
>>
>>     Personally I think a java.util.Utilities class containing nested
>>     static classes for Objects, Arrays, Collections, Strings, Maps
>>     etc, might have been a better way to organize such things. But
>>     it's probably too late now as the duplication would be very ugly.
>>
>>     David
>>
>>
>