What is the benefit for Collections.singleton() to return a Set instead of a Collection?

Question

The Collections.singleton() method returns a Set with that single argument instead of a Collection.

Why is that so? From what I can see, apart from Set being a subtype of Collection, I can see no advantage... Is this only because Set extends Collection anyway so there is no reason not to?

And yes, there is also Collections.singletonList() but this is another matter since you can access random elements from a List with .get()...

Answer 1

Immutable

The benefit is found in the first adjective read in that JavaDoc documentation: immutable.

There are times when you are working with code that demands a Set (or List, etc.). In your own context you may have a strict need for only a single item. To accomplish your own goal of enforcing the rule of single-item-only while needing to present that item in a set, use a Set implementation that forbids you from adding more than one item.

“Immutable” on Collections::singleton means that, once created, the resulting Set object is guaranteed to have one, and only one item. Not zero, and not more than one. No more can be added. The one item cannot be removed.

For example, imagine your code is working with an Employee object representing the CEO (Chief Executive Officer) of your company. Your code is explicitly dealing with the CEO only, so you know there can be only one such Employee object at a time, always one CEO exactly. Yet you want to leverage some existing code that creates a report for a specified collection of Employee objects. By using Collection.singleton you are guaranteed that your own code does not mistakenly have other than one single employee, while still being able to pass a Set.

Set< Employee > ceo = Collections.singleton( new Employee( "Tim Cook" ) ) ;  // Always exactly one item in this context, only one CEO is possible.  ceo.add( … ) ;     // Fails, as the collection is immutable. ceo.clear() ;      // Fails, as the collection is immutable. ceo.remove( … ) ;  // Fails, as the collection is immutable.  someReport.processEmployees( ceo ) ; 

Java 9: Set.of & List.of

Java 9 and later offers new interface methods Set.of and List.of to get the same effect, an immutable collection of a single element.

Set< Pet > pet = Set.of( someDog ) ; 

Sibling of methods are overloaded to accept any number of elements to be in the immutable collection, not just one element.

Set< Pet > pets = Set.of( someDog , someOtherDog , someCat ) ; 

Answer 2

I'm not sure there's a "benefit" or "advantage" per se? It's just the method that returns a singleton Set, and happens to be the default implementation when you want a singleton Collection as well, since a singleton Collection happens to be a mathematical set as well.