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
