3 Added comment about using Iterable
source | link

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.

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.

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.

2 I clarified my conclusion per Sergio's question.
source | link

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 pretty painlesseasy for your clientsa client to calluse, so I say don't implementdo not see a reason to provide the redundantvarargs API. Only provide the List API.

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 pretty painless for your clients to call, so I say don't implement the redundant API.

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.

1
source | link

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 pretty painless for your clients to call, so I say don't implement the redundant API.