[External] : Re: Q: List.of(E... elements) specification with regards to underlying array updates

[Eirik Bjørsnøs]

On Tue, Sep 2, 2025 at 7:54 PM Stuart Marks <stuart.marks at oracle.com> wrote:

Thanks Stuart for your excellent essay of an answer :-)

> If somebody is genuinely confused by the situation, we could add some
> clarifications.

I will confess that I was not genuinely confused. My assumption of an
"unmodifiable list" would be that it should be immutable, be it
through the front door or the back door.

> But if we didn't rely on implicit knowledge, the specifications
> would be unbearably cumbersome and verbose.

This is a fair point and satisfied my actual confusion which was more
about what is the right level of specification here. Where to stop.
This seems to be a bit of an art.

> The reason that List.copyOf's spec is explicit about modifications is that it needs
> to specify that it "makes a copy" while sometimes being allowed not to make a copy!

A side note: I assume this method would also simply be named "of" if
overloading resolution was not an issue.

> Most people's experience of List.of is something like
>
>     var list = List.of(a, b, c, ..., x, y, z);

I see your point. However, I think in fact people will mostly be using
one of the non-varargs methods, since call sites with more than 10
elements look rare. At least in the OpenJDK source code, the vast
majority calls this method with some actual array, not using varargs.
This may be different in regular non-platform code though.

But yes, even in the Javadoc itself it's not very clear that an array
is involved, so talking about it would be more awkward compared to
copyOf.

> However, without providing all this context, I'm skeptical that
> adding such a clause would provide much value.

I think this makes sense and satisfies my curiosity. Thanks again for
explaining!

Eirik.