Why do Guava classes provide so many factory methods instead of just one that takes varargs? [duplicate]

Question

Possible Duplicate:
Why does Guava's ImmutableList have so many overloaded of() methods?

Looking at Guava's ImmutableList (and some other classes), you'll find plenty of overloaded of convenience methods ("Returns an immutable list containing the given elements, in order.") that take a different number of parameters:

...
public static <E> ImmutableList<E> of(E e1, E e2, E e3) 
public static <E> ImmutableList<E> of(E e1, E e2, E e3, E e4) 
public static <E> ImmutableList<E> of(E e1, E e2, E e3, E e4, E e5) 
... 

All the way to this one:

public static <E> ImmutableList<E> of(E e1,
                                      E e2,
                                      E e3,
                                      E e4,
                                      E e5,
                                      E e6,
                                      E e7,
                                      E e8,
                                      E e9,
                                      E e10,
                                      E e11,
                                      E e12,
                                      E... others) 

Some colleagues of mine consider this silly, wondering why there's isn't just one method: of(E... elements). They suspect it's an ill-guided performance "optimisation" that falls into the category "do you think you're smarter than compiler", or something like that.

My hunch is that Kevin Bourrillion et al. put these methods in there for a real reason. Can anyone explain (or speculate) what that reason might be?

Answer 1

The comment in the source says:

// These go up to eleven. After that, you just get the varargs form, and
// whatever warnings might come along with it. :(

So, this was done because varargs methods produce a warning with generic arguments.

Answer 2

I think it's to avoid unchecked generic array creation warning when E is a generic type.

Answer 3

It's to avoid the overhead of creating a varargs array for the most common use cases. This is modeled after the way EnumSet.of(..) was designed.

Answer 4

Actaully the compiler is really dumb, the JVM has most of the smarts, but its still not smart enough to eliminate the need to create an array for a vararg.

Whether saving the array is really worth it, is perhaps something the author didn't want users to worry about. i.e. he might know it doesn't make much difference, but not all users might realise its not worth worrying about it 99% of the time.

When it was google-collections this was part of the description "High-performance immutable implementations of the standard collection types, for example ImmutableSet"

Answer 5

What I can think of is to avoid confusion by the compiler.

If we had only,

public static ImmutableList<E> of(E element); //Option 1

and

public static ImmutableList<E> of(E... elements);  //Option 2

and in your code we had

ImmutableList<String> list = ImmutableList.of("Value");

The compiler wouldn't know whether to call option 1 or option 2.

There must be a valid reason why Josh Bloch, Kevin Bourrillion and his team thought of having "ridiculous" of(...) method.