Helper classes

[Gregg Wonderly]

There may also be room for an annotation here that could point at classes which provide factory constructors.  The reason I say this, is that @see is a general documentation mechanism.   If there was an annotation introduced here, that an IDE could use, then it would make it possible for the IDE to go ahead and list the static factory methods as code completions as well.  Since the specifics are detailed by the annotation, there would be ample opportunity to exploit them to help developers, unlike @see which you have have javadoc "visible" to the IDE to get access to.

Gregg Wonderly

On Apr 15, 2013, at 2:23 PM, Paul Benedict <pbenedict at apache.org> wrote:

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