Unfortunately, collection literals were a proposal for Project Coin in Java 7 (and Java 8), but it never made it into the final product, aka it is not a feature of Java.
The proposition was this
Here’s how it would look with map literals:
    final Map<Integer, String> platonicSolids = { 
          4 : "tetrahedron",
          6 : "cube", 
          8 : "octahedron", 
          12 : "dodecahedron", 
          20 : "icosahedron"
    };
Here is the empty map literal, which has a slightly irregular syntax to make
it differ from the empty set:
    Map<String, Integer> noJokeHere = { : };
BUT it never happened, so unfortunately that doesn't work. So unless you write your own magic builder or fancy lambda like on this site of Per-Åke Minborg, you're on your own. The following from the site should work, though (in Java 8).
//copy paste from linked site
Map<Integer, String> map = Stream.of(
            new SimpleEntry<>(0, "zero"),
            new SimpleEntry<>(1, "one"),
            //...
            new SimpleEntry<>(11, "eleven"),
            new SimpleEntry<>(12, "twelve"))
            .collect(Collectors.toMap((e) -> e.getKey(), (e) -> e.getValue()));
And the simplified version, also from the site:
//copy paste from linked site
public static <K, V> Map.Entry<K, V> entry(K key, V value) {
    return new AbstractMap.SimpleEntry<>(key, value);
}
public static <K, U> Collector<Map.Entry<K, U>, ?, Map<K, U>> entriesToMap() {
    return Collectors.toMap((e) -> e.getKey(), (e) -> e.getValue());
}
Map<Integer, String> map = Stream.of(
            entry(0, "zero"),
            //...
            entry(12, "twelve"))
            .collect(entriesToMap());
Collection literals weren't introduced because of these points:
- The "simple" version of this feature (sets, lists, maps only) is not 
very satisfying or popular; the "extensible" version of this feature is 
open-ended, messy, and virtually guaranteed to way overrun its design 
budget; 
- The library-based version gives us X% of the benefit for 1% of the 
cost, where X >> 1; 
- Value types are coming, and the "what would this feature look like" 
in a world with value types may well be quite different than in a world 
without, suggesting it would be questionable to try and do this work 
before value types; 
- We are better off focusing our language-design bandwidth on 
addressing more the foundational issues underlying a library-based 
version (including: more efficient varargs, array constants in the 
constant pool, immutable arrays, and support for caching (and reclaiming 
under pressure) intermediate immutable results). 
By Brian Goetz from Oracle