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

Jim Gish jim.gish at oracle.com
Thu Apr 18 17:37:25 UTC 2013


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

Thanks >> 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 >>>>>>>>> On 04/17/2013 03:15 PM, Mike Duigou wrote: >>>>>>> String:: >>>>>>>> line 1253: This should use {@code } rather than . I think >>>> regular spaces are OK as well.   seems inappropriate. >>>>>>>> lines 2425/2467: elements may not be null either. >>>>>>>> I can tell you (or maybe it's just me) are itching to change : >>>>>>>> for (CharSequence cs: elements) { >>>> 2477 joiner.add(cs); >>>> 2478 } >>>>>>>> to: >>>>>>>> elements.forEach(joiner::add); >>>>>>>> StringJoiner:: >>>>>>>> -
isn't needed around
 as it's already a 
you
>>>> probably mean to do >>>>>>>>
 {@code
>>>> ... >>>> } >>>>>>>> for code samples. >>>>>>>> - It would be nice if the empty output generation in three arg >>>> constructor could be suppressed unless needed. Perhaps a special >>>> (not null >>>> please!) sentinel value? >>>>>>>> - Four arg constructor doesn't include emptyOutput in @throws NPE >>>>>>>>>>>> On Apr 11 2013, at 15:33 , Jim Gish wrote: >>>>>>>> Please review >>>> http://cr.openjdk.java.net/~*jgish/Bugs-5015163-7175206- >>>>> _*7172553/<http://cr.openjdk.java.net/~jgish/Bugs-5015163-7175206-7172553/><_ >>>>>>>>>> http://cr.openjdk.java.net/%**7Ejgish/Bugs-5015163-7175206-**7172553/<http://cr.openjdk.java.net/%7Ejgish/Bugs-5015163-7175206-7172553/> >>>>>>>>>> These are changes that we made in lambda that we're now bringing into >>>>> JDK8. >>>>>>>>>> I've made a couple of additions - making StringJoiner final and >>>>> adding a >>>>> couple of constructors to set the emptyOutput chars. >>>>>>>>>> Thanks, >>>>> 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 >>>>>>>>>>>>> -- >>> 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 >>>>>>>

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