var args constructors/methods vs lists

Question

In the long debate of using arrays vs lists in the public API of Java classes, I tend to prefer lists in most situations. However, I also found convenient to use var arguments in many constructors and methods, which require declaring an argument of the method (the last one) as an array (implicitly adding "..." before the parameter name).

Since in many of these methods I do want to provide a programmer the possibility to either explicitly list the arguments (with var args) or use a pre-defined collection when invoking the method, I often end up defining a constructor or method with var arguments, and an overloaded version that accepts a list instead of the var args array. For example:

public void myMethod(X ...items) {  
    myMethod(Arrays.asList(items));
}  

private void myMethod(List<X> items) {  
    ...  
}  

I know that in theory I do not need to overload the method replacing the var args array with a list if I want the programmer to send a collection of objects. He could just send an array.

The reason I often do this is because most (if not all) of the methods in my API use lists instead of arrays, and it is a bit weird that for one or two methods requirying collection of objects, the programmer needs to work with arrays (in cases when the var args are not convenient). So I provide an overloaded version working with list for consistency.

However, since this is a recurrent problem, I have the uncomfortable feeling of being writing boilerplate code too often. I would like to receive feedback if my motivation of keeping my interface consistent (accepting var arrays or lists, but not forcing the programmer to work with arrays if not really required) is valid enough to keep writing overloaded versions using lists for most of my methods requirying var arguments.

I would like to highlight that I know that for certain methods arrays could be more convenient than lists. My question concerns situations where the only motivation for declaring the last argument of the method as an array is because in certain scenarios using var arguments can be convinient.

UPDATE

Thanks for your feedback. My conclusions at the moment are the following:

• Reduce the usage of var args as much as possible.
• Continue adding an overloaded version of the method with var args, such as the array argument is replaced by a list (or an Iterable, as @Kevin pointed out), in cases where it can be useful to have the choice to invoke the method with either var args or with a collection.
• Stop using Java as soon as possible :) (I already knew that one)

Answer 1

You're overthinking the problem. You want to use a list (array or some other iterable) for your arguments when it's likely the consumer of your function would already have things in a list. You want to use variable arguments when you might want to call a function with a different number of arguments.

A classic example of when you should use varargs is C's printf(). Using varargs makes sense here because, in the general case, there's no reason to put a bunch of arbitrary values in a list just to print something. A good example of where you'd probably want a list is a sum() where you're probably operating on a bunch of related values that would likely be stashed away together.

It's not something you need to be dogmatic about or have rules for. Use some common sense and write code that people can follow & doesn't force you to jump through arbitrary hoops.

Answer 2

The only justification for a client wanting a varargs that I can think of is simply a style argument where it doesn't "feel" right for a client to group things together in a collection on their side.

An example might be when your client has several DAOs which implement a common interface but talk to logically distinct data sources, like a Customer table and an Address table. Although a client app might use a common interface to access this data, the query terms they use probably won't be the same for both (you might query Customers by last name but you wouldn't query Addresses that way). Since a client typically wouldn't have a use case to iterate over a List of that interface, they probably won't have naturally stashed those two DAOs in a list.

However, lists are a more useful data structure to work with than arrays. Dynamic memory allocation, .sublist(x,y), .clear(), iterators, etc are all handy to have which is probably why you are already in the habit of using lists on the backend. So why not expect the client calling your API feel the same way? Arrays.asList(item1, item2) is easy for a client to use, so I do not see a reason to provide the varargs API. Only provide the List API.

In addition, I don't agree with Kevin's comment that you should specify the Iterable interface in your API. You lose all of the useful APIs in the List interface just to save your client who has a set from calling "new ArrayList(set)" and passing that to your API. At a minimum your API should take a Collection.

Answer 3

Varargs is a bad idea in modern languages. It was a simplifying assumption in C, but should never have made the jump to Java or C# (C++ can be forgiven because it really wanted to be a superset of C). Any language that has a first-class List, even before generics and List<Object>, should be able to represent any varargs function much better with a list parameter. And if you eliminate varargs completely, a lot of method signatures that are ambiguous with varargs cease to be without.