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 < davidalayac...@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 <davidalayac...@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 <j...@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....@gmail.com> >>> >> To: "core-libs-dev" <core-libs-...@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 >>> >>
