RFR: String.join(), StringJoiner additions (original) (raw)

Jim Gish jim.gish at oracle.com
Fri Apr 19 16:54:06 UTC 2013

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.gish at 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.gish at oracle.com

More information about the core-libs-dev mailing list