<div dir="ltr">Just so there are some strawman arguments against: <br><br>* Does altering Set.of to maintain order increase its memory footprint? If the answer is yes, does that matter? If the answer is no, is there a new standalone collection type to add? <font face="monospace">SetThatIsOrderedInTheSameMannerAsPythonsSetIsOrderedAndThusHasNoNotableMemoryOverheadOrItHasMoreOverheadButItsWorthIt?</font><br>* Would it create an inconsistency between Set.copyOf and Set.of? I.E. Can both be ordered or just Set.of<br>* At a certain point it was decided to randomize iteration order of collections between runs. Will there be any place where that behavior would catch bugs that will now go uncaught. I.E. if code today is given a value of <font face="monospace">Set.copyOf(...)</font><font face="arial, sans-serif"> but that caller later updates what they provide to be </font><font face="monospace">new HashSet<>(Set.copyOf(...)).</font><font face="arial, sans-serif"> If so, does this outweigh the benefits of making it ordered? Is there any reason to make </font><font face="monospace">SequencedSet.of</font><font face="arial, sans-serif"> and </font><font face="monospace">Set.of</font><font face="arial, sans-serif"> return different kinds of sets?</font></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2025 at 7:58 AM David Alayachew <<a href="mailto:davidalayachew@gmail.com">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Sure, changing the return type to a more specialized type is never a problem. And even if it was, the explicit documentation on those factory methods was that the actual implementation is subject to change, and should not be depended on.</p>
<p dir="ltr">Also, your argument about iteration order doesn't make sense. It won't uncover bugs deterministically. It all depends on how things get grouped.</p>
<p dir="ltr">Also, if we are going to be returning a SequencedSet, then it would make good sense to change the javadoc to reflect the fact that iteration order can now be depended upon.</p>
<p dir="ltr">Either way, I don't really care which way we go. But I certainly think that altering Set.of to return SequencedSet is the stronger move, and I haven't heard any solid arguments against it.</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2025, 2:26 AM Rafael Winterhalter <<a href="mailto:rafael.wth@gmail.com" target="_blank">rafael.wth@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"> <div>Would it even be possible to change the return types of Set.of(...) and Map.of(...) without breaking binary compatibility?</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Best regards, Rafael<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 17. Jan. 2025 um 00:36 Uhr schrieb David Alayachew <<a href="mailto:davidalayachew@gmail.com" rel="noreferrer" target="_blank">davidalayachew@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">I should also add, the documentation went out of their way to specify that iteration order is unspecified.</p>
<p dir="ltr">Also, I see Rémi's comment, but that's even more unconvincing to me.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">When I get back, I can check myself.</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2025, 6:25 PM David Alayachew <<a href="mailto:davidalayachew@gmail.com" rel="noreferrer" target="_blank">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">I guess let me ask the obvious question.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Is there any way we can look this up in the bug database or something?</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2025, 2:28 PM Jens Lideström <<a href="mailto:jens@lidestrom.se" rel="noreferrer noreferrer" target="_blank">jens@lidestrom.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Having the result Map.of and Set.of preserve the insertion order would <br>
often be convenient.<br>
<br>
More often than not programs iterate over the contents of a maps and <br>
sets at some point. For example to present the values in a GUI, for <br>
serialisation, or even for error printouts. In all those cases having a <br>
fixed iteration order is much better than having a random iteration <br>
order.<br>
<br>
Often it is even a subtle bug to have a random iteration order. For <br>
example, I ran in to a situation where jdeps printed a error message <br>
containing a list of modules. But the list was in a different order on <br>
each run of the program! It took me a while to figure out that it was <br>
actually the same list. A possible explanation is that jdeps is <br>
implemented using Map.of or Set.of.<br>
<br>
Because of this I think I would be better if the most commonly used <br>
standard collection factories produced collections with a fixed <br>
iteration order.<br>
<br>
Guavas ImmutableMap and ImmutableSet also preserve insertion order.<br>
<br>
Regards,<br>
Jens Lideström<br>
<br>
<br>
On 2025-01-16 08:44, Remi Forax wrote:<br>
<br>
> -------------------------<br>
> <br>
>> From: "Rafael Winterhalter" <<a href="mailto:rafael.wth@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">rafael.wth@gmail.com</a>><br>
>> To: "core-libs-dev" <<a href="mailto:core-libs-dev@openjdk.java.net" rel="noreferrer noreferrer noreferrer" target="_blank">core-libs-dev@openjdk.java.net</a>><br>
>> Sent: Thursday, January 16, 2025 8:13:17 AM<br>
>> Subject: Factory methods for SequencedSet and SequencedMap<br>
> <br>
>> Hello,<br>
> <br>
> Hello,<br>
> <br>
>> I am happily taking SequencedSet and SequencedMap into use, but one <br>
>> inconvenience I encounter is the lack of factory methods for the two.<br>
>> In code where many (initial) collections have zero or one element (for <br>
>> later aggregation), I now write Set.of()/Set.of(one) and <br>
>> Map.of()/Map.of(key, value), as it makes the code shorter and more <br>
>> readable. Those collections are of course implicitly sequenced, but <br>
>> now I must make the variable type of the surrounding monad Set and <br>
>> Map, and simply assume that a LinkedHashSet or LinkedHashMap is used <br>
>> when a collection of more than one element is set, without requiring <br>
>> the interface type. This does not require any type casting, as I rely <br>
>> on the iteration order only, but the code loses some of its <br>
>> expressiveness.<br>
>> I did not find any discussion around introducing factories for <br>
>> SequencedSet.of(...) and SequencedMap.of(...), similar to those that <br>
>> exist in the Set and Map interfaces. Was this ever considered, and if <br>
>> not, could it be?<br>
> <br>
> Thanks for re-starting that discussion, it was talked a bit, but not as <br>
> it should be.<br>
> <br>
> So the issue is that currently we do not have any compact, unmodifiable <br>
> and ordered Set/Map implementation,<br>
> one use case is when you have data that comes from a JSON object as a <br>
> Map and you want to keep the inserted order, if by example the JSON is <br>
> a config file editable by a human, an other example is in unit tests <br>
> where you want to help the dev to read the output of the test so the <br>
> code that creates a Set/Map and what is outputed by the test should be <br>
> in the same order.<br>
> Currently there is no good solution for those use cases because <br>
> Set|Map.copyOf() does not keep the ordering.<br>
> <br>
> I see two solutions, either we add a new <br>
> SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation of <br>
> Set|Map.of()/copyOf().<br>
> Python had gone for the latter solution, which has the advantage a <br>
> being simple from the user POV, but from an algorithm expert POV, a Set <br>
> and a SequencedSet are different concepts we may want to emphasis ?<br>
> <br>
>> Best regards, Rafael<br>
> <br>
> regards,<br>
> Rémi<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>