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

[joe.darcy]

Hello.

Following up from threads earlier this year,

http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html

I'm willing and interested to sponsor getting String.join functionality
into JDK 7.

To address this particular bug, I think there should be new "join"
methods on String as opposed to a general "joiner" class.  A more
general class could be added later.

Remi, please point to a current draft of the specification and
implementation for your change.

Kevin, I'm interested in hearing your comments on the API design.

Thanks,

-Joe

[Remi Forax]

Le 14/10/2009 01:32, Joseph D. Darcy a écrit :

> Hello.
>
> Following up from threads earlier this year,
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html 
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html 
>
>
> I'm willing and interested to sponsor getting String.join
> functionality into JDK 7.
>
> To address this particular bug, I think there should be new "join"
> methods on String as opposed to a general "joiner" class.  A more
> general class could be added later.
>
> Remi, please point to a current draft of the specification and
> implementation for your change.
>
> Kevin, I'm interested in hearing your comments on the API design.
>
> Thanks,
>
> -Joe

Hi Joe,
the webrev is here:
http://cr.openjdk.java.net/~forax/5015163/webrev.00/
There is no specification, i.e no more than the javadoc.

I will dig this evening to find the tests I've used,
they are on another computer at home which is currently shutdown.

As Kevin said String.join is perhaps better as a static method,
see first part of:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001065.html

regards,
Rémi

[David Schlosnagle]

Hi Rémi,

One quick comment on AbstractStringBuilder.join(String, Object,
Object...) -- I'd propose to check that 'elements' is not null prior
to appending 'first' so that if the preconditions are violated and the
NullPointerException is thrown, there are no side effects. This would
also be a nice use of the proposed java.util.Objects
validation/precondition/assert methods. The other two join methods in
AbstractStringBuilder will implicitly throw NullPointerException when
getting the length or iterator respectively, both prior to any
modification to the underlying AbstractStringBuilder. I'd be in favor
of making those more explicit, but that is more of a stylistic
comment.

Thanks,
Dave Schlosnagle


On Wed, Oct 14, 2009 at 10:35 AM, Rémi Forax <forax@...> wrote:

> Le 14/10/2009 01:32, Joseph D. Darcy a écrit :
>>
>> Hello.
>>
>> Following up from threads earlier this year,
>>
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html
>>
>> I'm willing and interested to sponsor getting String.join functionality
>> into JDK 7.
>>
>> To address this particular bug, I think there should be new "join" methods
>> on String as opposed to a general "joiner" class.  A more general class
>> could be added later.
>>
>> Remi, please point to a current draft of the specification and
>> implementation for your change.
>>
>> Kevin, I'm interested in hearing your comments on the API design.
>>
>> Thanks,
>>
>> -Joe
>
> Hi Joe,
> the webrev is here:
> http://cr.openjdk.java.net/~forax/5015163/webrev.00/
> There is no specification, i.e no more than the javadoc.
>
> I will dig this evening to find the tests I've used,
> they are on another computer at home which is currently shutdown.
>
> As Kevin said String.join is perhaps better as a static method,
> see first part of:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001065.html
>
> regards,
> Rémi
>
>
>

[joe.darcy]

Rémi Forax wrote:

> Le 14/10/2009 01:32, Joseph D. Darcy a écrit :
>> Hello.
>>
>> Following up from threads earlier this year,
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html 
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html 
>>
>>
>> I'm willing and interested to sponsor getting String.join
>> functionality into JDK 7.
>>
>> To address this particular bug, I think there should be new "join"
>> methods on String as opposed to a general "joiner" class.  A more
>> general class could be added later.
>>
>> Remi, please point to a current draft of the specification and
>> implementation for your change.
>>
>> Kevin, I'm interested in hearing your comments on the API design.
>>
>> Thanks,
>>
>> -Joe
>
> Hi Joe,
> the webrev is here:
> http://cr.openjdk.java.net/~forax/5015163/webrev.00/
> There is no specification, i.e no more than the javadoc.
>
> I will dig this evening to find the tests I've used,
> they are on another computer at home which is currently shutdown.
>
> As Kevin said String.join is perhaps better as a static method,
> see first part of:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001065.html 
>

Yes, I'd also lean toward static methods for this functionality.

-Joe

[joe.darcy]

Joe Darcy wrote:

> Rémi Forax wrote:
>> Le 14/10/2009 01:32, Joseph D. Darcy a écrit :
>>> Hello.
>>>
>>> Following up from threads earlier this year,
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html 
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html 
>>>
>>>
>>> I'm willing and interested to sponsor getting String.join
>>> functionality into JDK 7.
>>>
>>> To address this particular bug, I think there should be new "join"
>>> methods on String as opposed to a general "joiner" class.  A more
>>> general class could be added later.
>>>
>>> Remi, please point to a current draft of the specification and
>>> implementation for your change.
>>>
>>> Kevin, I'm interested in hearing your comments on the API design.
>>>
>>> Thanks,
>>>
>>> -Joe
>>
>> Hi Joe,
>> the webrev is here:
>> http://cr.openjdk.java.net/~forax/5015163/webrev.00/
>> There is no specification, i.e no more than the javadoc.
>>
>> I will dig this evening to find the tests I've used,
>> they are on another computer at home which is currently shutdown.
>>
>> As Kevin said String.join is perhaps better as a static method,
>> see first part of:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001065.html 
>>
>
> Yes, I'd also lean toward static methods for this functionality.
>
>

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 assume the motivation for having both the Object[] and (Object,
Object...) versions is to avoid unnecessary array creation in the case
of one argument since the single method join(String, Object...) could
also be used.

-Joe

[weijun.wang]

Anyone will really use the single Object argument version? There's nothing
to join here.

- Max

------- Original message -------

> From: Joe Darcy <Joe.Darcy@...>
> Cc: core-libs-dev@...
> Sent: 23.10.'09,  9:49
>
> Joe Darcy wrote:
>    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 assume the motivation for having both the Object[] and (Object,
> Object...) versions is to avoid unnecessary array creation in the case of
> one argument since the single method join(String, Object...) could also be
> used.
>
> -Joe

[Remi Forax]

Le 23/10/2009 03:53, Joe Darcy a écrit :

> Joe Darcy wrote:
>> Rémi Forax wrote:
>>> Le 14/10/2009 01:32, Joseph D. Darcy a écrit :
>>>> Hello.
>>>>
>>>> Following up from threads earlier this year,
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html 
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-March/001191.html 
>>>>
>>>>
>>>> I'm willing and interested to sponsor getting String.join
>>>> functionality into JDK 7.
>>>>
>>>> To address this particular bug, I think there should be new "join"
>>>> methods on String as opposed to a general "joiner" class.  A more
>>>> general class could be added later.
>>>>
>>>> Remi, please point to a current draft of the specification and
>>>> implementation for your change.
>>>>
>>>> Kevin, I'm interested in hearing your comments on the API design.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>
>>> Hi Joe,
>>> the webrev is here:
>>> http://cr.openjdk.java.net/~forax/5015163/webrev.00/
>>> There is no specification, i.e no more than the javadoc.
>>>
>>> I will dig this evening to find the tests I've used,
>>> they are on another computer at home which is currently shutdown.
>>>
>>> As Kevin said String.join is perhaps better as a static method,
>>> see first part of:
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001065.html 
>>>
>>
>> Yes, I'd also lean toward static methods for this functionality.
>>
>>
>
> 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 assume the motivation for having both the Object[] and (Object,
> Object...) versions is to avoid unnecessary array creation in the case
> of one argument since the single method join(String, Object...) could
> also be used.

No.
The problem is that if there is only one method:
public static String join(String separator, Object... objects);
then a call to that method with by example an array of String will raise
a warning.

So this method was split (no pun intended) in two to avoid this warning.

>
> -Joe

Rémi

[Mark Reinhold]

> Date: Fri, 23 Oct 2009 10:10:35 +0200
> From: Rémi Forax <forax@...>

> 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

[Joe Kearney-4]

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@...>

> Date: Fri, 23 Oct 2009 10:10:35 +0200
> From: Rémi Forax <forax@...>

> 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

[Ulf Zibis-2]

Am 23.10.2009 17:51, Mark Reinhold schrieb:

>> Date: Fri, 23 Oct 2009 10:10:35 +0200
>> From: Rémi Forax <forax@...>
>>    
>
>  
>> 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.
>
>  

Hm, but of what object. The result of the join method should be the
object, we are talking about, but it doesn't exist in advance, so only a
constructor could serve those needs.
We also have the pair:
    public static String copyValueOf(char[] data)
    public char[] toCharArray()

-Ulf

[joe.darcy]

Yes, to my aesthetics the static call

    join(" ", "A", "call", "to");

is more sensible looking than

    " ".join("A", "call", "to");

Especially when a call like

    " ".join("Foo")

will not have " " in the returned String.  However, the platform would
certainly be improved with any version of String.join compared to not
having it.

-Joe

Joe Kearney 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
> <http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Joiner.html#on%28java.lang.String%29>)
> 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@... <mailto:mr@...>>
>
>     > Date: Fri, 23 Oct 2009 10:10:35 +0200
>     > From: Rémi Forax <forax@... <mailto:forax@...>>
>
>     > 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]

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@...> 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@...>

> Date: Fri, 23 Oct 2009 10:10:35 +0200
> From: Rémi Forax <forax@...>

> 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

[Stephen Colebourne-2]

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?

Stephen


2009/10/23 Kevin Bourrillion <kevinb@...>:

> 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@...>
> 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@...>
>>>
>>> > Date: Fri, 23 Oct 2009 10:10:35 +0200
>>> > From: Rémi Forax <forax@...>
>>>
>>> > 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
>
>

[Ulf Zibis-2]

Am 26.10.2009 14:01, Stephen Colebourne schrieb:
> Not wishing to confuse the debate, but perhaps the correct place for
> this is a static Strings class, that parallels Objects.
>
>  

-1

Doing this consequently we could have for each "normal" class
'ClassName' it's static helper class 'ClassNames', so we don't have any
static method in a normal class, and so we could drop this language
concept completely from Java and instead introduce a kind of Class,
where all method's are static by definition, similar to abstract class,
where all methods are abstract.


I assume, the first of the '...s'-classes was 'Arrays', introduced,
because array object's and there members (e.g. length) are not defined
via normal class syntax.
IMO, introducing '...s'-classes for whatever class is a bad idea, and
would satirize the existence of static methods at all, whose task it is
worthy, to provide helper functions to instances of objects, where they
are defined.

Reflecting about this, I would also prefer, to move those static Objects
class methods to existing java.lang.Object.
Having this, we wouldn't need to statically import those methods in any
class.

-Ulf

[joe.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@...>:
>  
>> 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@...>
>> 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@...>
>>>      
>>>>> Date: Fri, 23 Oct 2009 10:10:35 +0200
>>>>> From: Rémi Forax <forax@...>
>>>>>          
>>>>> 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
>>
>>
>>    

[David Holmes - Sun Microsystems]

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

[Neal Gafter]

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.

On Mon, Oct 26, 2009 at 9:29 AM, David Holmes <David.Holmes@...> 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

[joe.darcy]

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.

-Joe

>
> On Mon, Oct 26, 2009 at 9:29 AM, David Holmes <David.Holmes@...
> <mailto:David.Holmes@...>> 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
>
>

[David Holmes - Sun Microsystems]

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@...
>> <mailto:David.Holmes@...>> 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
>>
>>
>

[Stephen Colebourne-2]

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.
>
> 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:

http://commons.apache.org/lang//api/org/apache/commons/lang/StringUtils.html

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
focus.)

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....

Stephen