[ferd]

Applause! However, it's not always about "saving keystrokes"... it's about lowering accidental complexity and making code easier to reason about by requiring less cognitive load on the reader.

Another example: the lack of literals for collections in Java. Imagine this:

  Map x = {"a": "A", "b": "B"}; // not Java

vs:

  Map x = new java.util.HashMap();
  x.put("a", "A");
  x.put("b", "B");

The first case is more declarative, and thus easier to grasp. In the second case you have to read, parse and "execute" line by line in your head... (Does ordering matter? Does line 3 depend on line 2?, etc).

When things like these compound, you end up with code-bases many times bigger and harder to grasp than in other languages.

Granted: you can write shitty code in any language, nothing will save you from that... But I think Java makes it harder to write simple and concise code, even to experienced coders.

Then there's also the "cultural" thing many already mentioned ("enterprise Java")... which is very real, but no JEP/JSR will fix that ;-).

Brian shows brilliance, even at "trivial" issues. I trust his judgement :-).

[kubota]

    var ages = Map.of("sarah",19, "dan",35);   //valid java

[ferd]

Nice, glad to see that added to the standard API (even if a bit too late).

Stressing the point: this welcomed improvement on the API is a lot more than "saving keystrokes".

[jmartrican]

Map.of came out in JDK 9. I think there are still a lot of companies using JDK 8.... uhg. Maybe OP is one of the poor souls stuck in JDK 8.

[cesarb]

For those of us still using Java 8, ImmutableMap.of() (from Guava) is similar (and probably the inspiration for Map.of()), as long as you don't need your Map to be modified later.

[erik_seaberg]

We’re still using Java 8 in prod, because Java 9 broke our Hive version and a lot of other use cases for reflection (in return for modularizing stdlib, which we never cared about). I think some projects gave up on Java 9 as it neared EOL, and Java 11 compatibility still isn’t finished.

[jmartrican]

Nice touch using "var" to show that off too.

[RockingGoodNite]

var and static must die.

[jfengel]

Java is deliberately nudging you not to do things like that. It would rather you create a class with fields a and b -- which has its own verbosity, though they've improved it.

I find that I use structures like that primarily when interfacing with other loosely-typed languages, like Javascript, which do encourage you to create structures on the fly like that. Impedance mismatch is always a pain, no matter where it occurs.

That's not to say Java doesn't want you to use Maps. They do -- but only when the content is dynamic. They don't want to add literals for it because that's the opposite of their goal.

There are days when you want it anyway, and then you grumble that the language has forced you to do something ugly. But every language is a set of tradeoffs where some things are ugly, other things are pretty, and the language spec doesn't require a shelf of its own.

[ahtihn]

Unit tests very frequently need Map declarations like that.

[jfengel]

Unit tests are exactly one of those situations I had in mind. Unit tests are always kind of painful that way: you need to construct things by hand, using interfaces that were designed for automated use.

The same fact is what makes unit tests so brittle. Ideally, you do as little of that as possible: you less fake stuff you make, the more robust the test will be.

There are days you can't, and that sucks. But the language is giving you a nudge in the direction of how to do that, by making it easier to construct actual POJOs than unstructured intermediate data.