Hi, Viktor! On Thu, Sep 3, 2026 at 5:19 PM Viktor Klang <[email protected]> wrote: > > 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.
I see the reason, but I would rather keep it in ListFormat. I feel that even though both java.text and java.util (including java.util.stream) belong to java.base, the java.text API is more high-level, and java.util is more basic/fundamental. So I'd avoid code references from java.util to java.text. We indeed have some references from java.util to java.text (in Scanner, Pattern, Formatter, Calendar, Date, and Locale classes), but I'm reluctant to add more. Another thing is that instance methods are easier to use and easier to read. I like Remi's suggestion to add a cross-link from Collectors.joining to ListFormat.toCollector. A javadoc link is a weaker dependency, which looks acceptable here. Well, probably other maintainers have another opinion. If we post CSR, more people will participate in the discussion. > > (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 >
