Is there analog Collections.singleton() / Collections.singletonList() / Collections.singletonMap() to obtain mutable collection?

Question

I know if I have element and I want to get List/Set/Map with this element I can invoke :

Collections.singleton() / Collections.singletonList() / Collections.singletonMap()

At this case I get immutable collection(I cannot add/delete element to collection).

Is there analog to obtain mutable collection?

Answer 1

With the standard libraries you can use:

new ArrayList<...>(Arrays.asList(...)))
new HashSet<...>(Arrays.asList(...)))

These can take any number of elements as parameters. Libraries like guava have slightly more convenient methods:

Sets.newHashSet(...)
Lists.newArrayList(...)
Maps.newHashMap(ImmutableMap.of(...))

Answer 2

1. There would be no point for such API to exits, because you can always use the constructor that takes a collection (new ArrayList(Collections.singleton(whatever)))

2. If it existed it would be harmful. No sane API would allow you to choose an implementation of the new collection (eg. LinkedList vs. ArrayList) or additional parameters (like initial size).

Singleton collections are just very lean adapters for passing a single object to APIs that expect a collection. Having them mutable would defy the point entirely.

**Addendum (since, years after, I am still getting downvotes on this answer, so maybe something is not clear from the explanation) **

The singleton collections in the standard library are not "real" - they are implemented with a single attribute storing a single reference; there's no way to make them bigger. They are "fakes"; "stubs".

So why have them at all? It's a (minor) performance optimization: To create an immutable singleton collections - only one allocation is needed, whereas all the "real" collections require at least two. I.e.: even if we only store a single object in an ArrayList, the implementation needs to allocate an additional array. Even if we store a single object in a LinkedList, it needs to allocate a Node. And so on. No way around it.

Usually, a single additional allocation/object is not a problem, but in some performance-critical places - this will add up. So the standard library gives us a way to "create an extra-cheap stand-in for a real collection for the performance-critical places where full collection functionality is not required."

Returning a mutable collection from the singleton collections API would nullify the only reason why the API exists.

The confusion - probably - is because someone could interpret the "singleton" methods not as "algorithmical optimization" but as a "less typing and nicer code optimization". If this is your point of view, then indeed standard library could provide some sugar for "mutable singletons". It doesn't because we would be saving peanuts (literally a couple of chars, not even ten), while losing big - think about the overrides for creating different implementation (linkedList vs arrayList) or parametrizing the existing implemnetation (how would I create a singleton mutable ArrayList that preallocates space for 16 objects?)