In general, my experience has been that general APIs should return Collection types, not arrays. I agree with your perspective that arrays tend to provide too much of an internal representation, and lack flexibility.

However, I also prefer not to use java.util.Collection explicitly. I prefer using either List or Set (depending upon the way the method works). Obviously, in some situations, java.util.Collection is more appropriate. However, by specifying List or Set, it gives the user of the API more information about the organization of the data being returned, which is useful to the caller (such as whether there are duplicates, whether they can get direct access to an index, etc.). What irritates me is taking that too far and returning a Vector or Hashtable (usually done by programmers who aren't familiar with the collection framework).

The other concern with returning collections, though, is the common mistake (again, this is referring to more general APIs, and not closely tied code) of returning an internal collection (allowing the caller to mess around with the internals of a class outside of its context). This gets done with arrays, as well, though, so it's not necessarily exclusive to collections (I just see it done more often in those situations). Part of that may be the perception that an array copy is fast (i.e. it gets handled like a memcopy), so returning a copied array is quick (even though most collection implementations use internal arrays and use the same copy mechanism in their toArray() calls).

Anyway, I agree with you (though, that's without looking at the particular example). The speed savings are generally not worth the developer time, etc. to pay the price of a poor interface.

Dan