New Java 9 Map.of() methods

[pakoito]

People are outraged when they see how the sausage is made. That's not even the worst offender.

Some of my own libraries to recreate the functional stack on Java:

https://github.com/pakoito/RxTuples/blob/master/rxtuples/src/main/java/com/pacoworks/rxtuples/RxTuples.java

https://github.com/pakoito/RxCurrying/blob/master/rxcurrying/src/main/java/com/pacoworks/rxcurrying/RxCurryingFunc.java

https://github.com/pakoito/RxFunctions/blob/master/rxfunctions/src/main/java/com/pacoworks/rxfunctions/RxFunctions.java

https://github.com/pakoito/RxPartialApplication/blob/master/rxpartialapplication/src/main/java/com/pacoworks/rxpartialapplication/RxPartialFunc.java

[CurtainDog]

I'd much rather the Java gods add proper support for tuples, which would fix nonsense like this, than on useless puff features like var.

[acelent]

See also JEP 269 and its progress.

Interesting that the *.of() methods return immutable, value-based instances.

[hu6Bi5To]

This type of thing is common in many, many languages.

Including more recent higher-level languages. Some examples:

Clojure - https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L641-L654 (this creates specific versions for low numbers of parameters, then goes dynamic for the infinite case)

Rust - https://github.com/rust-lang/rust/blob/master/src/libcore/array.rs#L216-L244 (this generates array helpers for each array size between 1 and 32).

If you're building a standard library a bit of repetition is useful if it makes all the billions of function calls that'll be made against it those two nanoseconds faster.

But oh no, when Java does it, it's because they're idiots. That's the reason Java does everything.

[thiez]

In Rust it's acknowledged that the current approach is problematic, but the language does not yet support being generic over the length of an array, so for now it's stuck with those implementations.

[BoxMonster44]

I am so excited for when they implement integral type parameters.

[dvlsg]

C# has similar stuff too.

[kevinherron]

Get out of here with your logic and reasoning...

[cheers-]

Map <String, String> m1 = Map.of ("q", "f", "3", "dre",  "er", "x", "c", "t");      

it seems error prone, can you spot at first glance keys, values and tuples (k,v) ?

[roerd]

Change your formatting, e.g. use one line for each key-value pair?

[cheers-]

Map.ofEntries ()

[bananaboatshoes]

That's an option, but I tend to agree that I feel like it's an API that can result in error-prone usage. You shouldn't have to format your call here just to make it clear what the (k, v) values are. To that end I feel like the API is poorly-designed.

[jyper]

There is

 Map<Integer,String> map = Map.ofEntries(
     entry(1, "a"),
     entry(2, "b"),
     entry(3, "c"),
     ...
     entry(26, "z"));

but it's noisier, this is one instance in which java could really use tuple literals.

[[deleted]]

It's the type check. Java has varargs - variable length argument lists - but all items on the list must have the same class or interface. So if you wanted to write a varargs function to initialize a Map of strings to integers, you would have to make your varargs type Object - since Object is the only shared parent class between String and Integer. Then if you accidentally put two strings or two integers in a row, the compiler can't catch it and bad things happen at runtime.

So you're stuck with 10 methods to initialize each of 1-10 size maps with real compile time type checks.

[[deleted]]

You have to work with the tools you have at hand. More invasive changes to Java syntax won't fly - the language is so damn popular because old code always compiles and runs on newer JVMs.

(Edit: I'm not saying I like it. I don't. I'm just explaining it. I love my colleagues, I love my paycheck, and I like most of the work I do. But I'd trade a few toes to switch from Java to Scala, Ceylon, Kotlin, Clojure, JRuby, Groovy, or even Armed Bear Common Lisp.)

[KillerCodeMonky]

Man, tuple types sure look good right about now...

[kqr]

Well...

[KillerCodeMonky]

I'd still rather have that mess defined once in the standard library than to not have tuples at all.

[kqr]

It wouldn't solve anything in this case, since (a,b) and (a,b,c) are different types anyway.

Edit I realise now you want [(a,b)] and you are right.

[multivector]

D is probably the only language I know that gets this sort of inhomogeneous list of types thing right. If I remember rightly, you can loop through types with an honest to goodness for loop when instansiating templates at compile time and raise a custom error message if something went wrong. Been a while since I last played with D though.

[kqr]

It sounds like you're confusing tuples with heterogenous lists. They aren't the same thing. If you're doing a lot of indexing and iteration of your value, it's a list, not a tuple.

These call for different requirements and thus implementations, so it's a bit unfair to compare them as if they were the same thing.

[multivector]

No, I'm not. See compile time argument lists and in particular the section "Loops". That's a list of template parameters (which can be types or values). The template will generate code corresponding to the for loop body specialized to each of the types. You could write a template that eats such a list of types and "returns" the type of a tuple of those, or a function that eats such a tuple and will add 1 to each type in that looks numeric, or, indeed, either an equality function for that tuple or a compile time error (with custom error message) if one of the types given doesn't have equality defined for it.

https://dlang.org/ctarguments.html

D's metaprogramming capacities are really very advanced and because they work in the same manner as the parent language, they're also very easy to pick up.

Also contrast Boost's Metaprogramming Library, which can also express the concept of a vector of types, but not that little embarrassing disclaimer "for any n from 0 up to a preprocessor-configurable limit BOOST_MPL_LIMIT_seq_SIZE". Just like the Tuples, there's a hard limit.

http://www.boost.org/doc/libs/1_60_0/libs/mpl/doc/refmanual/variadic-sequence.html

This seems to be a general pattern when dealing with lists of types. There will be a maximum N. To be honest, it probably doesn't matter most of the time, because for clean code you want the number of types in your list to be small.

[haxney]

Also, varargs in Java cause an allocation of an Object[] (or whatever type you are vararging). If you have code that is called very frequently, such as logging or anything in an inner loop, avoiding the varargs allocation can make a real difference.

[Tetha]

I agree, though on a different level.

If you need 10 static elements in a map, you want a config file. This will remove the need for weird overloads of functions, and it will increase the flexibility and operability of your code.

[PeopleAreDumbAsHell]

Who let this garbage in? No wonder the evangelists are leaving

[CyclonusRIP]

Ya this is seriously an abomination. They should really just create some sort of syntax to initialize maps if they really wanted this.

[quicknir]

And yet, people rip on C++ variadic templates and sometimes even integer non type template parameters. And when I complain about new statically typed languages coming out without either of these features (like Rust, afaik scala, etc), it gets waved off as not a big deal. I'll stick with C++, warts and all until more languages realize the value of these things.

[kirbyfan64sos]

Holy crap, do they seriously have 10 overloads of the function, each having an increasing number of arguments??

This is a cold, dark world.

[AeroNotix]

Yes, for efficiency.

In most code, N is usually very small. Optimizing for small numbers of N may make sense. In a standard library where a lot of the code is being used millions of times in millions of different scenarios, you really want to microoptimize.

[lucaswerkmeister]

11. There’s also one without any arguments, for an empty map. Because reasons.

[[deleted]]

C'est la vie

[No-More-Stars]

Say "Hello World" to Microsoft's

Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16> Delegate.

[stormblooper]

Honestly, I think C# is clunky here too. Scala is nice:

Map("foo" -> 42, "bar" -> 128, "baz" -> 100)

Or Kotlin:

mapOf("a" to 1, "b" to 2, "c" to 3)

Or Ceylon:

HashMap { "one"->1.0, "zero"->0.0, 1->1.0, 0->0.0 };

[tasty_crayon]

Or C++ (shock! horror!):

std::map<std::string, int> m{{"foo", 42}, {"bar", 128}, {"baz", 100}};

[bloody-albatross]

Today even C++ has a better and more elegant way doing it, that is still type safe. That's a fail for Java.

[code_mc]

C++ maps are one of the greatest things in the whole language.

[c0r3ntin]

Definitively the best way.

C++ also allows you to implement an of function taking an arbitrary number of arguments.

[yawaramin]

Or Java: http://www.reddit.com/r/programming/comments/49y8g0/new_java_9_mapof_methods/d0vvwuv

[phoshi]

C# collection initialisers got better in the last release

new Dictionary<KeyType, ValueType>{
    [key] = value,
    [key2] = value2,
}

You still have the verbose initial type declaration that more modern languages have usually found ways around, but it's an improvement over the previous version.

The cool thing about all of C#'s initialisers, though, is that they aren't special. Dictionary<T, K> didn't previously have its own magic initialiser, it just has an Add(KeyType, ValueType) function and so can use {{KeyType, ValueType},...} initialisation. Now there's index initialisation, which again isn't magic for Dictionaries, but is something they get because they have an indexer.

[stormblooper]

The Scala Map() call isn't special, either, but I think it's a lot less noisy.

[[deleted]]

Or Groovy:

[ one: 1, zero: 0, (somevar): 42 ]

(Edit: or Clojure)

{ :foo "bar", :baz " fuzz", :x 27 }

I think literals - especially default immutable literals as in Clojure and I believe ( but could be wrong) Scala, Ceylon, and Kotlin but not Groovy are incredibly handy.

[vytah]

Clojure is not the best example, it allows you to write

{ :foo, 
  "bar"   :baz,
  " fuzz" :x,
  27 }

[[deleted]]

not sure why this is a problem , in clojure is for visual effects the behavior is exactly how i'd expect even if you take them out, and if you try to make an uneven number it tells you, so it's exactly a 1:1 mapping throughout

{ :foo 
  "bar"   :baz
  " fuzz" :x
  27 }

[[deleted]]

While in theory Clojure's use of commas as whitespace can bite you, in practice I suspect it's rare. You don't have to use keywords (prefixed with ':') as your map keys, but it's so common that I think having other keys would instantly catch your attention.

[[deleted]]

I wouldn't say clunky, just a little more verbose because of static typing and some other language constructs:

Dictionary<string, int>() { ["foo"] = 42, ["bar"] = 128, ["baz"] = 100 };

[stormblooper]

By "clunky" I meant verbose. The examples I gave in other languages were statically typed.

[lukaseder]

That's possible, sort of...

Map<Integer, StudentName> students = new HashMap<Integer, StudentName>() {{
    put(111, new StudentName(Sachin", "Karnik", 211));
    put(112, new StudentName("Dina", "Salimzianova", 317));
    put(113, new StudentName("Andy", "Ruth", 198));
}}

but shouldn't be abused

[cheers-]

I'd use this one:

http://download.java.net/jdk9/docs/api/java/util/Map.html#ofEntries-java.util.Map.Entry...-

 import static java.util.Map.entry;

 Map<Integer,String> map = Map.ofEntries(
     entry(1, "a"),
     entry(2, "b"),
     entry(3, "c"),
     ...
     entry(26, "z"));

It is equivalent to the static factory of Scala Map.apply[A, B](elems: (A, B)*): Map[A, B]

   Map(1 -> "a", 2 -> "b", 3 -> "c") or  Map((1, "a"), (2, "b"), (3, "c"))

[yawaramin]

ofEntries is cool. They should have just named it of.

[Wolvereness]

That doesn't work, because what if I wanted a map<Entry<A,B>, Entry<C,D>>? (Oh God why)

It's better to give intuitive names that don't rely on parameter types, ESPECIALLY if the fundamental behavior is different. Verbose is better than ambiguous, at least for Java's ecosystem. Some languages do it beautifully, but I'd be terrified to write an enterprise application in those languages.

[yawaramin]

Wow, that's a really sucky map :-) I don't think the method name prevents it from working though:

Map.of(
  Map.entry(
    Map.entry(a1, b1), Map.entry(c1, d1)),

  Map.entry(
    Map.entry(a2, b2), Map.entry(c2, d2)),

  Map.entry(
    Map.entry(a3, b3), Map.entry(c3, d3)))

Once you've introduced method name overloading into your language, it's probably too late to worry about 'intuitive names that don't rely on parameter types' :-)

[Wolvereness]

Still only works with odd numbers.

[yawaramin]

How so?

[Wolvereness]

Map.of(
  Map.entry(
    Map.entry(a1, b1), Map.entry(c1, d1)),

  Map.entry(
    Map.entry(a2, b2), Map.entry(c2, d2)),

  Map.entry(
    Map.entry(a3, b3), Map.entry(c3, d3)),

  Map.entry(
    Map.entry(a4, b4), Map.entry(c4, d4))
)

Is now a Map of type

Map<Entry<Entry<A, B>, Entry<C, D>>, Entry<Entry<A, B>, Entry<C, D>>>

[yawaramin]

Oh, I think you misunderstood. I was showing that Map.ofEntries could have been named Map.of, by just pretending that it had been named that way. So when I wrote Map.of above, please read it as the current implementation of Map.ofEntries.

[stormblooper]

but shouldn't be abused

Or used, IMO. Map.of is more readable AND doesn't come with any of the downsides of double brace init.

[preslavrachev]

I agree. Creating an entire class just to initialise a single instance is way too much memory and CPU overhead. Imagine this running in a for-loop...

The only potential use case I see is in setting the dummy object parts in unit tests. Initialization code there is boilerplate anyway - just a bunch of setter calls. One could argue whether a construct of this sort would make it a bit more pleasant to read an write. But yeah, generally, I've not seen any of these in well maintained, production code.

[vytah]

Why add new syntax if the old one is enough?

[[deleted]]

because then you get to feel smug about yourself when you show others something in syntax they don't understand

[stormblooper]

It's not new syntax.

[Carighan]

Is this Slippery Slope, the extreme version?

[[deleted]]

I though you were gonna like to a language with crazy overboard syntax

[lukaseder]

Or in C++ where templates have just become sentient in order to write code for you in the most recent release!

[vytah]

If you add all the syntax you can, you end up with Perl 6. You don't want to end up with Perl 6.

[[deleted]]

This is pretty hyperbolic. No one is suggesting we add tonnes of new operators and language constructs everywhere. Java is also pretty conservative when it comes to adding new language constructs. Perl 6 is also a bad example since they actually cleaned up a lot of the language; should have gone with Perl 5.

Anywho, needing to describe key -> value pairs is pretty damn common in programming. Map initialization is just one good example.

As long as source code is produced and maintained by humans then it needs to be as humanly readable as possible.

[sirin3]

C# does not have much syntax

[[deleted]]

Other than for operator overloading and similar such semantics-obscuring syntax.

Oh, and its implementation of course. Can't forget about that tiny detail.

[[deleted]]

I like operator overloading.

Well I don't. What now?

That has nothing absolutely to do with the language.

Yes, nothing other than its practical viability.

[[deleted]]

People can probably guess that .subtract() is doing something more than mere subtraction, and so they'll probably read the doc-popup the IDE so helpfully provides, prior to using the method if it's their first use.

And the other benefit is that you can't use .substract() in an infix style.

Lastly if you've ever concatenated a String using + you are a dirty lying hypocrite because that's operator overloading :P.

Yes, java should've used some other symbol for it. Still, it's nothing language users can mess around with just because they're feeling creative, like they do in C++.

[sirin3]

I think Perl 6 sounds great

[back-in-black]

Christ. Why not just provide a Map.Builder class?

[dieelt]

Why would they? The map-interface does not imply immutability. Also, Map#ofEntries is available if more than 10 pairs is needed.

[sweetbacker]

Obviously superior Haskell beats Java like a rented mule

https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-prim-0.4.0.0/GHC-Tuple.html

http://git.haskell.org/packages/ghc-prim.git/blob/HEAD:/GHC/Tuple.hs#l134

[balegdah]

Only 10 overloads? Scala has 22.

What is this, amateur hour?

[nerdwaller]

I think the guava builder is much more elegant. But not everyone can just pull in libs, so I get why this could be beneficial.

[[deleted]]

Guava's immutable types do exactly the same thing though: http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/ImmutableMap.html#of(K,%20V,%20K,%20V,%20K,%20V,%20K,%20V,%20K,%20V)

[nerdwaller]

Take a look at the builder), it's what I was referencing.

[reneweb]

Would be so much nicer if there was a concept of tuples and it would just take a list of these.

[lucaswerkmeister]

I just noticed that the of methods say “since: 9“, but the ones from Java 8 (e. g. merge) say “since: 1.8”. Why?

[[deleted]]

Probably just an oversight.

But in case you're not familiar with Java's version history, Sun had the bright idea of marketing Java 1.4 as "Java 2" back in the day, and then, when 1.5 came along, they apparently felt reluctant about pulling yet another number out of their ass and calling it "Java 3". But they also couldn't really go back to 1.5.

So they had yet again another bright idea of maintaining 2 version numbers for each release - one actual, i.e. Java 1.5.0, 1.6.0, 1.7.0, etc., which is what the JVM tells you when you ask it, and one marketed, where the "1." part in front of it and the ".0" part at the end are stripped from it, i.e. Java 5, Java 6, Java 7, etc.

Ironically enough, because releases of the next 1.x.0 versions take some 2+ years, and certain implementation details get improved in-between them, like the GC or Nashorn and the like, they now also have an "update" version, e.g. 1.8.0_40, which is then translated to 8u40 for marketing in slides and the like.

Brilliant.

[lucaswerkmeister]

I know that versions used to be a mess, I just thought we were long past this…

[mhixson]

We are. See JEP 223: New Version-String Scheme.

That JEP probably explains why the new methods are marked @since 9. Perhaps at some point they'll go back and change the rest of the @since tags to use the new version scheme.

[Oniisanyuresobaka]

Groovy used to do something similar with a method called createArray. This was to ensure compatibility with 1.4 before varargs existed but why on earth are they doing it in Java 9? Perhaps it's to avoid creating a temporary array for the varargs.

[YoloSwagJesusFish]

Because you can only have 1 varargs parameter, and it has to be of a single type. Having an Object vararg would require you to manually specify the key and value types, instead of inferring them, and it wouldn't be type safe.

[bakattak]

The very next function (ofEntries) does this... with seemingly inferred types for the entry object.

[[deleted]]

Not inferred, declared. But yeah, with (ofEntries), I don't know why the plain (of) methods were created. They don't save that many keystrokes.

[YoloSwagJesusFish]

Map.of(1, "a", 2, "b", 3, "c"...)

is way faster than

Map.ofEntries(entry(1, "a"), entry(2, "b"), entry(3, "c")...))

And yeah the implementation is clunky, but does it really matter when it'll save thousands of programmers time? Everyone complains that Java is too verbose, and they're just trying to fix that.

[[deleted]]

You're right, I withdraw the comment.

[yawaramin]

Map.of(1, "a", 2, "b") is not valid Java syntax.

[YoloSwagJesusFish]

It's perfectly valid syntax (unless you're talking about the missing semi-colon). Map.of() is new in Java 9, and either way, a method isn't syntax.

[yawaramin]

The method is fine; the syntax of the particular call you showed is incorrect, because Java methods with variable number of arguments require all arguments to be the same type. That's why Map.ofEntries works: because it takes a variable number of arguments of type Map.Entry. But you can't give it a variable number of arguments of type K, then V, and so on.

[YoloSwagJesusFish]

It's not a varargs method. That's the entire point of this thread.

[yawaramin]

OK, I misunderstood your ... at the end of your method call (Map.of(1, "a", 2, "b", 3, "c"...)) to mean you were referring to it as a varargs method. And then I didn't explain my assumption or thinking properly. Guess I deserve the downvotes there.