brian.goetz at oracle.com
Mon Apr 15 05:54:41 PDT 2013
Yes, for reasons Maurizio outlined, we're leaving this to last. But it
is more subtle than "just leave everything in Foos" or "move everything
from Foos to Foo."
The "bag of static methods" classes often tend to be dumping grounds,
and we definitely do not want interfaces to suffer the same fate. For
example, look at Collections. Even if the move could be done easily and
compatibly and without disruption, I would definitely *not* be in favor
of moving everything from Collections into Collection -- too many of
them are too unimportant to live in the interface.
The methods in Streams are all candidates, but that's actually only been
true for a few days. Before we split off the low-level methods into
StreamSupport, I would have said "we definitely will not move all of
these methods into Stream."
So, while this gives API designers one more tool, there don't seem to be
obvious hard and fast rules about how to use this tool yet, and the
simple-minded "all or nothing" candidates are likely to give the wrong
So, yes, to be considered, and was already on the to-do list on my desk
On 4/15/2013 4:53 AM, Stephen Colebourne 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(),
> Making the change might also affect some method names, as sometimes
> they read differently, or are otherwise confusing, when on the
> As a note, on JSR-310, we did move the methods from similar static
> helper classes to the interfaces:
> although I'm not sure that counts as precedent yet.
More information about the lambda-dev