Hi Sens,
It does make sense in general to select List types as parameters where arrays are expected. But I am curious as to what specific functionality is being used from the List interface ? I am taking a somewhat wild guess that the API ultimately ends up calling a "toArray()" method to get an actual array representation of the Collection and then uses indexed access directly on that array rather then relying on Java SDK's List features. (I might be wrong... like I said I am guessing)
The "toArray()" method is actually very conveniently located in the Collection interface rather than in List interface
Anyways, some more background on this. This is what I tried...
I tried by creating a class which simply wraps a Set in a List, something like this...
class SetAsList<E> implements List<E> {
private static final UnsupportedOperationException UNSUPPORTED = new UnsupportedOperationException();
private Set<E> mySet;
public void wrap(Set<E> theSet) {
mySet = theSet;
}
// Implement all the methods enforced by List
// Throw UNSUPPORTED from the methods which exposed indexed functionality of a List for e.g. public E get(int index)
}
Then use the above class to actually wrap a key set from a HashMap which contains names of the Vservers. The use that SetAsList object to set the "List of instances" as per the API method signature.
And it worked !
If it were relying on any List specific functionality it would have thrown the runtime exception UNSUPPORTED.
Now, I am not saying this might be true for all possible statistics Objects, but it might be worthwhile taking a look into the code and possibly introducing additional methods which accept Collection type parameters. This will make the API a lot more consumer friendly. I am sure API consumers will heavily rely on HashMap based data structures (i.e. Maps and Sets) to interact with the appliances using the API and will possibly run up against cases such as the one I have come across.
--
Gagan Grewal
