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
