Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7
Joe.Darcy at Sun.COM
Fri Oct 23 01:53:27 UTC 2009
Joe Darcy wrote:
> Rémi Forax wrote:
>> Le 14/10/2009 01:32, Joseph D. Darcy a écrit :
>>> Following up from threads earlier this year,
>>> 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.
>> Hi Joe,
>> the webrev is here:
>> 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:
> Yes, I'd also lean toward static methods for this functionality.
Following up on this, what is the exact revised proposal?
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...
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.
More information about the core-libs-dev