Sorry I am not receiving emails from core-lib-dev earlier. What I did was to remove things we considered not absolutely required, which left us only a StringJoiner class and two String.join methods.
StringJoiner was intended to be used with Stream as a collector, thus prefix, and suffix is desired like Collection.toString(). Cheers, Henry On Apr 19, 2013, at 9:54 AM, Jim Gish <jim.g...@oracle.com> wrote: > Hi Henry, Can you please comment on the simplifications you did ? > > Thanks, > Jim > > On 04/18/2013 07:38 PM, Ulf Zibis wrote: >> Am 18.04.2013 19:37, schrieb Jim Gish: >>> >>> On 04/18/2013 08:49 AM, Ulf Zibis wrote: >>>> Hi, >>>> >>>> I'm wondering, that StringJoiner has some logic for pre/suffix, but >>>> nothing to loop the elements themselves :-( >>>> >>>> To me, StringJoiner is a useless complicated box around StringBuilder, and >>>> imagine, someone needs thread-safety. >>>> It also slows down performance, as it needs additional instances and >>>> additional class to be loaded (critical at VM startup). >>>> >>>> Instead please add to StringBuilder and StringBuffer: >>>> append(CharSequence... elements); >>>> append(char delimiter, CharSequence... elements); >>>> append(char delimiter, Iterable<? extends CharSequence> elements); >>>> cut(int len); // removes len chars at the end of the sequence >>>> optional: >>>> append(CharSequence delimiter, CharSequence... elements); >>>> append(CharSequence delimiter, Iterable<? extends CharSequence> elements); >>> I started off with something similar, but it was stripped out when Henry >>> did the performance improvements. >> >> Hm, I have no idea, how above suggestions should prevent performance >> improvements. Can you help me? >> >>> Given that most people feel that this is going to be put to heavy-weight >>> usage, it doesn't seem to merit too much emphasis on performance or >>> complicating the implementation at this point. >> >> Your implementation has >> 1 class with 7 methods >> 2 additional methods in String >> To cover the same functionality, above approach basically only needs 2 >> additional methods in StringBuilder, has better performance, so what is >> complicated on that? >> >> @Martin: What is your opinion? >> >> Thanks, >> >> -Ulf >> >> >>>> For performance reasons, append should always append the trailing >>>> delimeter, which could be cut at the end. >>>> >>>> It's questionable, if class string needs a static (=no relation to an >>>> existing string in contrast to non-static split()) join method, as it >>>> seduces to >>>> "[" + String.join(...) + "]" >>>> which needs some effort from javac side to optimize to a single >>>> StringBuilder task. >>>> IMO we better had StringBuilder.join(...), so javac could easily optimize >>>> to: >>>> new StringBuilder().append('[').append(',', >>>> someStrings).cut(1).append(']').toString() >>>> >>>> -Ulf >>>> >>>> >>>> Am 18.04.2013 00:07, schrieb Martin Buchholz: >>>>> I'm still wondering about whether a joiner utility should support a prefix >>>>> and suffix. The obvious uses for this are collection class toString >>>>> methods, but we already know that we can and should implement those with a >>>>> single precise char[] construction, so should not use StringJoiner, or at >>>>> least not this StringJoiner implementation. And if we're just talking >>>>> about pure convenience, it's hard to beat >>>>> >>>>> "[" + String.join(...) + "]" >>>>> >>>>> >>>>> On Wed, Apr 17, 2013 at 2:49 PM, Jim Gish <jim.g...@oracle.com> wrote: >>>>> >>>>>> Here's an update: http://cr.openjdk.java.net/~** >>>>>> jgish/Bugs-5015163-7172553/<http://cr.openjdk.java.net/~jgish/Bugs-5015163-7172553/>< >>>>>> >>>>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7172553/<http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7172553/> >>>>>> >>>>>> Jim >> > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.g...@oracle.com >