Comparator and Comparators

[Brian Goetz]

Yes, it sure would be nice if there were some easily communicated, 
objective criteria to differentiate between a "good" and "bad" API.  And 
if you discover it, you'll be famous!  But until then, designing good 
APIs will have as much art as science.

But, if you read between the lines, there is some actionable advice 
here, which is that the decision of where to put static methods is not 
an obvious one, and that you need to expend a portion of your design 
budget here.


On 6/24/2013 10:56 AM, Paul Benedict wrote:
> Brian, can you explain the "judgement and taste" is required comment?
> I've been trying to find some objective criteria why someone should use
> static method in interfaces over static utility classes. I haven't found
> any reason except such vague comments, which are unhelpful. I do ask in
> earnest what should be the driver to use this new feature over existing
> designs. What criteria do you use?
>
> Paul
>
>
> On Mon, Jun 24, 2013 at 9:48 AM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     For this issue, Comparators will be going away soon as a public class,
>     and its members sent to various places:
>        - Comparator for common comparator factories
>        - BinaryOperator for Comparator-to-BinaryOperator transforms
>        - Map.Entry for specialized comparators on Map.Entry
>
>     You can see this in lambda repo if you're interested.
>
>     In general, people who want to believe "I can put static methods in
>     interfaces now, so code that used to go in class Foos now belongs in
>     interface Foo" will be disappointed (if they're smart).
>
>     The set of methods that are acceptable in a "statics dumping ground"
>     class Foos are not necessarily the same set as would be appropriate in
>     the Foo interface.  Judgment and taste is required.
>
>     On 6/24/2013 10:36 AM, Boaz Nahum wrote:
>      > Hi
>      >
>      > Now we have two places to look for factory methods:
>      >
>      > Comparator
>      > Comparators
>      >
>      > What is the rule ?
>      >
>      > Stream factories are in Stream,
>      > Collection factories are in Collections  (nothing we can do about it)
>      > Collector are in Collectors
>      > function.* are in function.*
>      >
>      > I know it is not big issue.
>      >
>      > Thank
>      > Boaz
>      >
>
>