Comparator and Comparators

[Paul Benedict]

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> 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
> >
>
>