Why Collections.emptySet(), Collections.emptyList() & Collections.emptyMap() ?

[Ranjan Maheshwari]

The java.util.Collections class provide methods as follows -
Collections.emptySet()
Collections.emptyList()
Collections.emptyMap()

These methods return the empty immutable Set, List and Map respectively. Why someone will ever need these methods?

[Mr. C Lamont Gilbert]

Its a type of programming idiom. This is for people that do not want null variables. So before the set gets initialized, they can use the empty set.

private Set myset = Collections.emptySet();

void initSet() {
   myset = new HashSet();
}
void deleteSet() {
   myset = Collections.emptySet();
}

public boolean setExists()
{
  if(myset.equals(Collections.emptySet()))
  {
      return false;
  }
  else return true;
}

[Mike Simmons]

Alternately, people might just use a constructor to create a new empty set, list, or map, rather than call one of these methods. But the Collections methods offer a couple of advantages:

1. They're more concise because you don't need to explicitly type out the generic type of the collection - it's generally just inferred from the context of the method call.

2. They're more efficient because they don't bother creating new objects; they just re-use an existing empty and immutable object. This effect is generally very minor, but it's occasionally (well, rarely) important.

[Mr. C Lamont Gilbert]

Sorry. That method exists because its parameterized for generics but the static variable is not.

[Mike Simmons]

Why "sorry"?

[Mr. C Lamont Gilbert]

Because my long explanation is not really the correct answer. Its true, but its not the reason the methods exist when there are already static variables.

[Rob Spoor]

The static variables Collections.EMPTY_SET etc are remainders from before generics. They are indeed not generic; all these methods do is cast these static variables to add a generic type. That won't give any problems since you can't add anything to them anyway.