Helper classes

[Paul Benedict]

IMO, adding static methods to interfaces for the sake of discoverability is
a poor language choice. Call me a purist, if you must, but interfaces are
meant to be design contracts. Attaching static methods to these is like
adding a third leg (very unnatural) -- it's a language feature that doesn't
pull its own weight. Having utility classes is good enough. If you must
know where to find concrete factory methods, adding @see tags to the
interface will suffice.

Paul


On Mon, Apr 15, 2013 at 1:36 PM, Sam Pullara <spullara at gmail.com> wrote:

> I think we should also consider discoverability. It would be a lot
> easier for IDEs to discover things like factories if they are on the
> interfaces they create implementations for. For example, if the
> Collector factories were on Collector it might make them easier to
> find.
>
> Honestly if something doesn't make it's weight to be on the interface
> maybe it doesn't make it's weight to be in the JDK. To me, I thought
> adding static methods to interfaces were to get rid of these junk
> classes. I can see how we might want to adjust javadocs to make them
> clearly separated.
>
> Sam
>
> On Apr 15, 2013, at 10:46 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> > Yes, I agree with this sentiment.  It's clear that:
> >
> >  - Never put methods that would have gone in class Foos into interface
> > Foo from now on
> >
> > and
> >
> >  - Always put the methods that would have gone in class Foos in
> > interface Foo from now on
> >
> > are both equally naive guidelines.  Which means that getting things
> > right will require a lot of careful thought, and that mistakes will be
> > made as we figure out the new rules.
> >
> > To the specific point, I agree that these two 310 classes are a good
> > example of where we should still consider a class; an interface with one
> > abstract interface method and a dozen implementations (when there could
> > as easily be half a dozen or three dozen) seems distinctly fishy.
> >
> > I think a key distinction is whether the implementations provided are
> > simply there for convenience (i.e., any competent user of the API could
> > have written them, but we provide them so you don't have to) or there
> > because they cannot be provided from outside (perhaps because they
> > require the use of otherwise private implementation detail.)  Because in
> > the former situation, the interface is clearly *more important* than the
> > implementations (arguing for putting the implementations elsewhere),
> > whereas in the latter case, they are equally important as one cannot
> > live without the other (justifying why they should live in the same
> place.)
> >
> > On 4/15/2013 1:13 PM, Zhong Yu wrote:
> >> On Mon, Apr 15, 2013 at 3:53 AM, Stephen Colebourne
> >> <scolebourne at joda.org> wrote:
> >>> Currently, Project Lambda has a number of helper clases, notably
> >>> Collectors and Streams, which are clearly related to the interface.
> >>> Since JDK8 has static methods on interfaces, are there plans to move
> >>> the static methods to the interface?
> >>>
> >>> This would allow methods such as  intBuilder(), emptyIntStream() and
> >>> singletonIntStream(int t) to be on IntStream rather than on Stream,
> >>> and thus have the simpler names of builder(), emptyStream(),
> >>> singletonStream().
> >>>
> >>> Making the change might also affect some method names, as sometimes
> >>> they read differently, or are otherwise confusing, when on the
> >>> interface.
> >>>
> >>> As a note, on JSR-310, we did move the methods from similar static
> >>> helper classes to the interfaces:
> >>>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/f4d50e8cc9e2/src/share/classes/java/time/temporal/TemporalAdjuster.java
> >>>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/f4d50e8cc9e2/src/share/classes/java/time/temporal/TemporalQuery.java
> >>> although I'm not sure that counts as precedent yet.
> >>
> >> Stephen, I feel it's ok to include one or two static factory methods
> >> in an interface - it was very annoying to have to create another class
> >> just to host one or two methods.
> >>
> >> But in the two examples provided by you, there are a too many factory
> >> methods, maybe they do belong to a separate class. Just from the
> >> javadoc point of view, it doesn't feel right to say "this is an
> >> interface of something; and by the way, a dozen of factory methods are
> >> defined here too"
> >>
> >> Zhong Yu
> >
>
>