On Sat, 17 Oct 2026 08:10:17 GMT, Tagir F. Valeev <[email protected]> wrote:
>> @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.
@amaembo I think those are sensible arguments. @AlanBateman, wdyt?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32716#issuecomment-6266568887
