Quoting Jeremy Daggett <[email protected]>:
Picking back up on this topic... I am actually leaning towards option 1 now. One thing that is really handy with varargs is that rather than providing multiple methods, we can have a single method in an interface. It could really simplify the APIs for our users. For example, if an API has a no-arg "list()" method, we could express it as a single method in the interface "list(ListOptions...)".
...which, I think, was exactly the original intention. But it leaves us unintentionally allowing you to call "list(ListOptions, ListOptions, ListOptions, ...)", which simply makes no sense.
How much simplification for the users do you think this would be, by the way? There would be no *code* changes required for users, just one fewer Javadoc method to parse. That's nice, of course, but if one of the methods simply refers directly to the other in the Javadoc, I hope people won't have trouble finding the right one.
It *would* certainly allow us to cut down on method definition when creating APIs, but personally I tend to agree with Ignasi in that I'd rather make implementers define an extra method than make it possible for users to make nonsensical API calls.
Perhaps we could cut down on the annotation overhead for implementers by "inheriting" the annotations from the overloaded method?
ap
