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.<br><br><div class="gmail_quote">

On Mon, Oct 26, 2009 at 9:29 AM, David Holmes <span dir="ltr"><<a href="mailto:David.Holmes@sun.com">David.Holmes@sun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Joseph D. Darcy wrote:<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Stephen Colebourne wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Joe, would you be prepared to sponsor a Strings class, and see join on<br>
there instead of String?<br>
  <br>
</blockquote>
<br>
No.<br>
</blockquote>
<br></div>
+1.<br>
<br>
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.<br>
<br>
But that also means I'd prefer to see additional static methods in Object, rather than the added Objects class.<br>
<br>
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.<br>

<font color="#888888">
<br>
David<br>
</font></blockquote></div><br>