On Thu, 15 Oct 2026 11:41:15 GMT, Viktor Klang <[email protected]> wrote:
>> I updated the PR according to the latest suggestions:
>> - ListFormat.toCollector restored
>> - Collectors.joining(ListFormat) replaced with joiningConjunctively and
>> joiningDisjunctively accepting a Locale
>> - Every collector now produces an empty string for the empty stream.
>
> @amaembo Thanks for your patience. I've taken some time to think about this
> PR.
>
> Currently I am a bit on the fence about this feature, and I think that there
> are a couple of questions I think needs some elucidation before deciding how
> to move forward.
>
> 1. We currently don't really have any APIs that produce Collector instances
> outside of Collector and Collectors.
> 2. What's the likelyhood of someone looking for this Internalization-feature
> will look for it in Collectors? I can definitely see that if they find
> ListFormat they might discover a toCollector()-feature, however how likely is
> it for someone to be looking at Collectors.joining to decide that
> "joiningDisjunctively" vs "joiningConjunctively" is the right choice for them?
>
> I suspect that what we'll see is that there is a split between users coming
> to this from ListFormat and some who come from Collectors. What's uncertain
> to me, at this time, is if this is 50/50 or 90/10.
>
> At the end of the day, I want to make sure that we expand the API surface for
> the right reasons and with care.
Hi, @viktorklang-ora
Regarding 1, I think that until now all collectors we had were very generic and
related to core APIs (collections, basic math, string concatenation). On the
other hand, internationalization is not that basic API, and it looks natural to
have a collector closer to the API than in the common `Collectors` class. It
also allows the collector to potentially access the `ListFormat` internals,
which may open room for optimization. It's quite possible that we may have
API-specific collectors in the future. For example, one may want to collect to
JsonArray if we have JSON API. Having such a collector somewhere near the
JsonArray class would be more natural. You may also compare with stream
sources. We have basic sources in the `Stream` class, like
`of/iterate/generate`, but many domain-specific sources are in corresponding
classes outside Stream API.
Regarding 2, I think that many developers today simply use `joining(", ")`,
because it's good enough for them, and they don't bother formatting in a better
way. Now, they will see new options like `joiningConjunctively` and may easily
discover that at a very low cost they can make the output more user-friendly,
even if their application is English-only. I think it's good to have common
options next to `joining`, as this will promote internationalization in general
and increase the amount of properly internationalized code. Probably some
people using `Collectors` were not aware at all that Java includes such great
internationalization capabilities. Discovering `joiningConjunctively` people
may eventually discover `ListFormat` and other formatting features, which could
be educational.
On the other hand, people who already know about `ListFormat` and care about
proper message formatting, may discover `toCollector` method inside
`ListFormat`, and migrate existing code like `lf.format(stream.toList())` to
`stream.collect(lf.toCollector())` making it more fluent and potentially more
performant.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32716#issuecomment-6231575277
