RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8

[Jim Gish]

Thanks Rémi,

I'll take a look at defender methods on Iterable.

As far as the parameter checks on String -- I had the same "Aha!" moment 
as soon as I got in my car to drive home on Friday.  However, it does 
come down to a philosophy of style in that I'm in favor of (1) catching 
and reporting errors as soon as possible, and (2) not depending on the 
implementation details of other methods (particularly other classes) of 
which I'm a client.  On the other hand, given this is "core" I realize 
that performance matters as well as locality of reference, so there is a 
trade off between deferring the check and sharing the static result 
message string.

Let's see what others think.

As far as transient on the static field -- I also realized as I was 
driving away that statics might not be serialized so transient is 
unnecessary.

Thanks,
    Jim

On 04/27/2012 07:01 PM, Rémi Forax wrote:
> Hi Jim,
> Yes, I've basically try to submit a patch each time I've written a 
> method join
> in one of my application :)
>
> The funny think (in fact it's even not funny) is that I think that 
> this methods
> should not be in String anymore. In Java 8, we will have defender methods
> so you can write join directly on an Iterable. And there is some 
> discussion
> to also allow defender methods on arrays too,
> so we may can write a method join on Object[] too
> (on an interface inherited from Object[] to be precise).
>
> I really think that list.join(",") is better than "".join(",", list) and
> ["foo", "bar"].join(",") is better than "".join(",", ["foo", "bar"]).
> but maybe I'm wrong.
If we do this, maybe the method should be called "list.joinWith( String 
delimiter )" instead of "list.join( String delimiter )"
>
> About the patch, you don't need to check the parameter in String because
> you will test them in AbstractStringBuilder.
> Given that you don't have to store the exception message in String 
> anymore.
> (by the way, the static fields are declared transient which is really 
> weird,
> as far as I know, we don't serialize static field values).
>
> Rémi
>
> On 04/28/2012 12:21 AM, Jim Gish wrote:
>> This enhancement proposal  has a long history.  The most recent 
>> attempt to get some String.join() methods was by Joe Darcy back in 
>> 2009 ( 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-October/002967.html) 
>>
>>
>> He started with the changes that Remi Forax had done 8 months prior 
>> to that, which Remi had attempted a year before that!
>>
>> I've taken the work that Remi and Joe did and am trying again.
>>
>> There was a lot of discussion that was generated and that is why this 
>> has died on the vine a number of times.  I realize that the current 
>> proposal may also generate discussion, but I think this had merit 4 
>> years ago and still does.  We won't satisfy everyone.  It may not be 
>> perfect (what is?!), but if we can look at it from the perspective 
>> that something is better than nothing, then we ought to attempt a 
>> quick review and get this in.
>>
>> Having said that, I ask that you please take a look at the 
>> http://cr.openjdk.java.net/~jgish/5015163/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejgish/5015163/webrev/>
>>
>> Just a few words, based on the previous discussion, to set some context.
>>
>>  * join() is (roughlty) intended to be the inverse of split()
>>  * example:  "Hi there".join("-", "Bill", "Joe", "Zoe") will yield "Hi
>>    there-Bill-Joe-Zoe"
>>  * in the original proposal the delimiter character was what you
>>    started with, i.e.
>>      o      "-".join( "Hi there", "Bill", "Joe", "Zoe") yielded the
>>        same result as above
>>      o it seemed awkward to have the delimiter be the String instance
>>        that the join was performed on.  I agree and so have made the
>>        first parameter of the join be the delimiter.
>>  * there was a lot of discussion about the pros and cons of making
>>    join() a static method vs an instance method.  The point was made
>>    then, and I concur, that given that split() is an instance method,
>>    it only makes sense that join() be one too.  Certainly there are
>>    other perspectives on this and one could argue the merit of each and
>>    every one of them, but in the interests of progress,  I think the
>>    the split()/join() similarity argument is the most compelling and
>>    natural.
>>
>>
>> Thanks,
>>    Jim Gish
>>
>>
>