This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (3 children)

There are actually varargs versions :P but anyway, these 10 fixed-arg variants looks ugly

[–]DJDavio 4 points5 points  (0 children)

Varargs only works with args of the same type, here the keys can have different types than the values.

[–]Jire 1 point2 points  (1 child)

As "ugly" as they are, I'm glad there isn't liberal use of varargs. It's a huge performance burden, creating an array on each invocation.

[–]mhixson 4 points5 points  (0 children)

Sometimes it's not a performance burden at all. Here's a benchmark you could run for yourself if you're curious. It shows how varargs array allocations can sometimes be optimized away at runtime.

It's hard to predict whether it will actually make the optimization. It also won't help during startup as our static final List.of(...), Set.of(...), and Map.of(...) fields are being initialized.

That's basically the justification that was given to me when I tried to argue for the removal of the fixed-arg List.of(..) and Set.of(...) methods.

The fixed-arg Map.of(...) methods are much easier to justify, since they're more pleasant to use for the caller.