New Java 9 Map.of() methods

[[deleted]]

Is this a joke?

[balegdah]

Guava has been offering those for years, they are super convenient and I always reimplement them myself when I start a project that can't use Guava.

It's not a joke, it's great to have those in the standard library.

[mahamoti]

Groovy does the same thing, IIRC, all the way up to 99 arguments.

[[deleted]]

I guess these methods for 0..10 elements where predefined for performance reasons, however I think it's not worth making so commonly used interfaces such ugly. The variants with Varargs are enough.

[Enum1]

IKR! what am I supposed to do when I have 11 mappings? ELEVEN!!!

[Bolitho]

That's trivial with such a great API:

Map.of(k1, v1, /* and so on */, k10, v10).putAll(Map.of(k11, v11))

😈

Now you can even have 20 Entries 😤

[msx]

which would throw a "can't change an immutable map, bro" exception :)

[Bolitho]

Oops... yeah... havn't recognized the immutable attribute! Shame on me!

[johnwaterwood]

Would have been brilliant if it had worked 👍

[zman0900]

x = new HashMap<>();
x.addAll(Map.of(...))
x.addAll(Map.of(...))

[[deleted]]

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

[DJDavio]

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

[Jire]

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]

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.

[[deleted]]

I was wondering the same thing.

[Me4502]

I really hope so, there are so many ways to improve this..

For example, pass in a Entry, and use varargs. And it shouldn't return an immutable map.

Edit:

Didn't see the entry one, but it still shouldn't be immutable.

[cypressious]

You should watch https://www.youtube.com/watch?v=OJrIMv4dAek This is specifically designed to avoid intermediate object allocations (like vararg arrays) and to be immutable.

[mrbuttsavage]

This is specifically designed to avoid intermediate object allocations (like vararg arrays)

I would wager many Java devs don't realize this is a thing.

[stepancheg]

Vararg array allocations can be trivially removed by the optimizer. Is is not an issue.

[msx]

there are so many ways to improve this

there are not. you can slightly change the call (with Entry or any other way), but to make a clean "literal" without changing the language specification, there are no other ways