Factory methods for SequencedSet and SequencedMap

[Rafael Winterhalter]

Would it even be possible to change the return types of Set.of(...) and
Map.of(...) without breaking binary compatibility?

I also think that the randomization of Set.of(...) and Map.of(...) is a
good property as it uncovers bugs early if one relies on iteration order.
This especially since those methods are often used in tests where
production code would use a proper HashSet which cannot guarantee iteration
order for good reasons. Exactly here I think the new interfaces are a good
addition as it uncovers such misconceptions. If code relies on insertion
order, providing a Set.of(...) does no longer compile, what is a good thing.

To me, adding SequencedSet.of(...) and SequencedMap.of(...) sounds like the
right approach, with implementations similar to that of Set.of(...) and
Map.of(...). As for megamorphism, I think the chance of encounter at a call
site is similar, as Set12 and SetN from the Set interface are typically
combined with HashMap. As for a possible SequencedSet12 and SequencedSetN,
I think they would normally be seen with LinkedHashSet.

Best regards, Rafael

Am Fr., 17. Jan. 2025 um 00:36 Uhr schrieb David Alayachew <
davidalayachew at gmail.com>:

> I should also add, the documentation went out of their way to specify that
> iteration order is unspecified.
>
> Also, I see Rémi's comment, but that's even more unconvincing to me.
>
> Map.of has an upper limit of 10 entries, and Map.ofEntries has an upper
> limit of that Java max file size limit thing. You all know what I am
> talking about.
>
> Point is, both of these static factories were meant to be used on a small
> number of entries. If it truly has just been not done until now, then the
> bug database will confirm that easily.
>
> When I get back, I can check myself.
>
> On Thu, Jan 16, 2025, 6:25 PM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> I guess let me ask the obvious question.
>>
>> Chesterton's fence -- why wasn't this done before? I refuse to believe
>> that this idea wasn't thought up years ago, which leads me to believe there
>> was a reason that it hasn't been done.
>>
>> Is there any way we can look this up in the bug database or something?
>>
>> On Thu, Jan 16, 2025, 2:28 PM Jens Lideström <jens at lidestrom.se> wrote:
>>
>>> Having the result Map.of and Set.of preserve the insertion order would
>>> often be convenient.
>>>
>>> More often than not programs iterate over the contents of a maps and
>>> sets at some point. For example to present the values in a GUI, for
>>> serialisation, or even for error printouts. In all those cases having a
>>> fixed iteration order is much better than having a random iteration
>>> order.
>>>
>>> Often it is even a subtle bug to have a random iteration order. For
>>> example, I ran in to a situation where jdeps printed a error message
>>> containing a list of modules. But the list was in a different order on
>>> each run of the program! It took me a while to figure out that it was
>>> actually the same list. A possible explanation is that jdeps is
>>> implemented using Map.of or Set.of.
>>>
>>> Because of this I think I would be better if the most commonly used
>>> standard collection factories produced collections with a fixed
>>> iteration order.
>>>
>>> Guavas ImmutableMap and ImmutableSet also preserve insertion order.
>>>
>>> Regards,
>>> Jens Lideström
>>>
>>>
>>> On 2025-01-16 08:44, Remi Forax wrote:
>>>
>>> > -------------------------
>>> >
>>> >> From: "Rafael Winterhalter" <rafael.wth at gmail.com>
>>> >> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> >> Sent: Thursday, January 16, 2025 8:13:17 AM
>>> >> Subject: Factory methods for SequencedSet and SequencedMap
>>> >
>>> >> Hello,
>>> >
>>> > Hello,
>>> >
>>> >> I am happily taking SequencedSet and SequencedMap into use, but one
>>> >> inconvenience I encounter is the lack of factory methods for the two.
>>> >> In code where many (initial) collections have zero or one element
>>> (for
>>> >> later aggregation), I now write Set.of()/Set.of(one) and
>>> >> Map.of()/Map.of(key, value), as it makes the code shorter and more
>>> >> readable. Those collections are of course implicitly sequenced, but
>>> >> now I must make the variable type of the surrounding monad Set and
>>> >> Map, and simply assume that a LinkedHashSet or LinkedHashMap is used
>>> >> when a collection of more than one element is set, without requiring
>>> >> the interface type. This does not require any type casting, as I rely
>>> >> on the iteration order only, but the code loses some of its
>>> >> expressiveness.
>>> >> I did not find any discussion around introducing factories for
>>> >> SequencedSet.of(...) and SequencedMap.of(...), similar to those that
>>> >> exist in the Set and Map interfaces. Was this ever considered, and if
>>> >> not, could it be?
>>> >
>>> > Thanks for re-starting that discussion, it was talked a bit, but not
>>> as
>>> > it should be.
>>> >
>>> > So the issue is that currently we do not have any compact,
>>> unmodifiable
>>> > and ordered Set/Map implementation,
>>> > one use case is when you have data that comes from a JSON object as a
>>> > Map and you want to keep the inserted order, if by example the JSON is
>>> > a config file editable by a human, an other example is in unit tests
>>> > where you want to help the dev to read the output of the test so the
>>> > code that creates a Set/Map and what is outputed by the test should be
>>> > in the same order.
>>> > Currently there is no good solution for those use cases because
>>> > Set|Map.copyOf() does not keep the ordering.
>>> >
>>> > I see two solutions, either we add a new
>>> > SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation of
>>> > Set|Map.of()/copyOf().
>>> > Python had gone for the latter solution, which has the advantage a
>>> > being simple from the user POV, but from an algorithm expert POV, a
>>> Set
>>> > and a SequencedSet are different concepts we may want to emphasis ?
>>> >
>>> >> Best regards, Rafael
>>> >
>>> > regards,
>>> > Rémi
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250117/dfd365d6/attachment-0001.htm>