Generified code that uses collections ends up writing this sort of thing all over the place:
    Set<String> strings = new HashSet<String>();
or even:
    Map<String,List<ObjectName>> map = new HashMap<String,List<ObjectName>>();

Having to duplicate the type parameters in the variable declaration and the constructor invocation is tedious and error-prone.  This could be greatly improved by the addition of methods like this to java.util.Collections:

    public static <T> Set<T> newSet() {
        return new HashSet<T>();
    }

and likewise for List, Map, SortedSet, and SortMap.  Now you can write:

    Map<String,List<ObjectName>> map = Collections.newMap();

The compiler's type inference allows it to know what kind of Map<K,V> to return here, just as it does for the existing Collections.emptyMap() method.  The specification should guarantee that the returned  customer  serializes as a HashMap but probably does not need to say that it actually is a HashMap.

Another big advantage of these new methods would be that programmers would no longer need to learn that the canonical implementations of Set List Map SortedSet SortMap are HashSet ArrayList HashMap TreeSet TreeMap, as if they were verb conjugations.  ("I can't remember if the past tense of SortedSet is HashSet, TreeSet, or ArraySet.")  These concrete implementations would then only be of interest for serialization or for programmers who imagine they can improve the performance of their programs by supplying an initialCapacity to the constructor of HashSet etc.

Ideally there would also be versions of the "copy constructors" for the various types, though that ends up meaning a lot of methods, e.g.:
    public static <K,V> SortedMap<K,V> newSortedMap();
    public static <K,V> SortedMap<K,V> newSortedMap(Comparator<? super K>);
    public static <K,V> SortedMap<K,V> newSortedMap(Map<? extends K,? extends V>);
    public static <K,V> SortedMap<K,V> newSortedMap(SortedMap<K,? extends V>);

N/A

N/A

Better to fix the language to behave more consistently.

remove generics please

This problem really irks developers universally.

The ideal solution would be a language change proposed by Neal Gafter which would allow for constructor type inference.  This would let you switch from

Map<String,List<Foo>> map = new HashMap<String,List<Foo>>();

to

Map<String,List<Foo>> map = new HashMap<>();

In the event that the language change does not carry, the second-best solution is to add newInstance() methods to all concrete Collection implementation classes, which parallel the constructors.

In this case, one could switch from

Map<String,List<Foo>> map = new HashMap<String,List<Foo>>();

to

Map<String,List<Foo>> map = HashMap.newInstance();

It's worth noting that if this were done for the "copy constructors" as well as the parameterless constructors, the signatures could be safely generalized from "Collection<? extends E>" to "Iterable<? extends E>".