Just chiming in,
I suspect that more developers know/use Collectors.<x>() than
ListFormat, so for discoverability purposes I suspect that a
Collectors.listFormatting(…) would be better.
(Note that I am not taking any stance as to whether this functionality
ought to be added or not)
On 2026-09-03 11:52, Tagir Valeev wrote:
Hello, Remi! Thank you for your comments.
On Thu, Sep 3, 2026 at 10:39 AM Remi Forax <[email protected]> wrote:
Being an instance method of ListFormat is a nice idea, i'm sure you can come
with a better implementation because you have access to the private state of
ListFormat.
I was thinking about this, but it looks like maintaining a partial
concatenation could be actually slower than maintaining the list of
things to join. It's especially problematic for parallel streams. I
looked into StringJoiner history, which is kinda similar (though
simpler). It had StringBuilder inside initially, but then was modified
to keep an array of elements, which is actually faster. So it looks
like keeping an intermediate list is ok. We could shave a little bit
of overhead building an array instead of List, as internally we need
an array, but it's unlikely that this will help significantly.
There are indeed possible ways to improve the performance of
ListFormat.format. We can completely avoid creating a MessageFormat
instance, and we can even delegate to private String#join(String,
String, String, String[], int) creating a proper prefix and suffix.
This could be much faster than the current implementation, especially
for big inputs. However, such performance improvements are subject to
a separate discussion.
I would prefer a name like "toCollector()" more than "formatting", given it's
an instance method of ListFormat
stream.collect(listFormat.toCollector())
vs
stream.collect(listFormat.formatting())
I'm fine with both options.
With best regards,
Tagir Valeev
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
