Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7
David.Holmes at Sun.COM
Mon Oct 26 18:00:04 UTC 2009
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.)
>> 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?
>> 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.
More information about the core-libs-dev