On Wed, 30 Sep 2026 12:23:32 GMT, Viktor Klang <[email protected]> wrote:
>> src/java.base/share/classes/java/text/ListFormat.java line 420: >> >>> 418: return Collectors.collectingAndThen( >>> 419: Collectors.mapping(String::valueOf, >>> Collectors.toList()), >>> 420: input -> input.isEmpty() ? "" : format(input)); >> >> If this proposal goes ahead then I assume the prototype implementation will >> be replaced. It looks like the most efficient way would be for the >> accumulator to accumulate in a StringBuilder for the "middle elements", with >> the finishing handling the 0, 1, 2, 3 and > 3 cases. > > I agree with Alan here. IIRC ListFormat is specified to be immutable, so it > should be possible to create a Collector implementation that creates a lot > less intermediate objects. I'm against using StringBuilder right here now for a number of reasons. 1. List resize is generally cheaper than StringBuilder resize because we need to copy less memory, so we may end up doing things worse with StringBuilder. Note that `StringJoiner` had originally `StringBuilder` inside, but it was replaced later with `String[] elts` (building the final string only during the finishing phase). 2. For parallel collection, this would complicate the combining step and intermediate copying of underlying byte[] arrays with special handling of middle elements. It could be significantly slower than appending two lists. 3. When we construct a human-readable message, in most of the cases it will be short (probably up to ten elements). In this case, I doubt that shaving microseconds is very important. Normally, we don't generate millions of human-readable messages per second because no human would be able to read them. 4. If we consider that performance is important here, it's much more reasonable to optimize the underlying `ListFormat.format`, so that non-collector clients may benefit as well. There's a big room for optimization: we don't need to form an intermediate format-string at all, we can produce the result directly. I think it could be times faster. For now, I see an opportunity to get rid of `mapping` step and inline a little bit of code to reduce intermediate checks. This change is implemented. I suggest to concentrate on simplicity and correctness here and postpone performance improvements to a separate pull-request where we may do microbenchmarking to justify any changes. I can work on it as well after this one gets merged. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32716#discussion_r4152695539
