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.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
On 04/17/2013 03:15 PM, Mike Duigou wrote:
String::
line 1253: This should use {@code } rather than <code></code>. 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::
- <blockquote> isn't needed around <pre> as it's already a <div> you
probably mean to do
<pre> {@code
...
}</pre>
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.g...@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.g...@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.g...@oracle.com
