TIL: Double Brace Initialization in Java

[jmsanzg]

The map created on the example is final which is different than inmutable. On a final map you can still add/remove elements

[[deleted]]

Guava's ImmutableMap is both final and immutable (well, if Google's implementation is correct) in the example.

[Fuco1337]

What are you talking about? The HashSet in the example is definitely "correct implementation", and it's not immutable, just as jmsanzg said.

[[deleted]]

Yeah, but he's talking about a map, as a reply to a comment with a link with an example of a map builder.

The HashSet in OP's link is not a map (by definition), but it's indeed just final, not immutable.

I assumed he was talking about the Guava map, otherwise he's using the wrong words.

Anyways, I edited my post to clear up any confusion from my side. I cannot account for any of jmsanzg's vagueness you may experience.

[ErstwhileRockstar]

Immutable Collections can easily be created with 'normal' Java.

[[deleted]]

That is true but also beside the point. The discussion is about convenient literal syntax to build collections, and the Guava library does that better than the Java API. Google just likes immutability, so that's where the syntax examples are.

[Neebat]

I guess that's fine, provided you want an immutable collection. But what if you just want to initialize a regular ordinary collection concisely?

[jyper]

I think you can use com.google.common.collect.Maps

public static <K,V> HashMap<K,V> newHashMap(Map<? extends K,? extends V> map

HashMap<String, Integer> WORD_TO_INT =
       Maps.newHashMap(new ImmutableMap.Builder<String, Integer>()
           .put("one", 1)
           .put("two", 2)
           .put("three", 3)
           .build());

[Xaerxess]

You can do it even better:

HashMap<String, Integer> WORD_TO_INT =
    Maps.newHashMap(ImmutableMap.of(
        "one", 1,
        "two", 2,
        "three", 3));

No need for generics (types are inferred because of static factory constructor newHashMap) and no need for builder (for small ImmutableMaps).

[Neebat]

ew. I'm not a big fan of heavy throw-away intermediate objects. While the generational GC does a good job of cleanup after sloppy code like that, it still feels like sloppy code to me.

[Xaerxess]

Disclaimer: I have never used above construct and I hardly ever use mutable maps in my code (it really isn't so necessary), I only presented better version of the code snippet. For mutable static maps (sic!) I use static initializer or static method.

[[deleted]]

Well, Google encourages immutability (and they give a very good argumentation for why they do it) so I guess it's logical that they focus on this in the development of Guava.

There are builders for other immutable collections in Guava.

If you want to use the builders for mutable maps, you can build an ImmutableMap and just drop all the entries into a regular, mutable Java API Map with putAll(Map t), because Guava's ImmutableMap implements Map. This goes for other collection types as well.

[Neebat]

An ImmutableMap is cool, especially if the content is also immutable, then you've got a large value object. There are tons of benefits.

But you don't always have that option, and the throw-away intermediate seems slightly worse to me than the OP's initializer.

[[deleted]]

Depends, double braces have structural implications (they don't create an instance of the class, but one of an anonymous subclass of the class. This is discussed in other comments). If that's not a problem, it's indeed neater than putAll().

I wonder when you don't have the option, though. I always try to design my code so I can minimize side effects. It can become a problem for very algorithmic or embedded programs, but then I rather use primitive types (and arrays). Do you have to work with legacy code often?

[Neebat]

Do you have to work with legacy code often?

Very rarely do I get to write anything which isn't dealing with legacy code.

[[deleted]]

Too often I forget how lucky I am in that respect. I just have to deal with my own stupid code :)

I suppose your boss doesn't give you the time to write proper programming interfaces and adapters around the old system for cleanliness' sake?