Helper classes

Brian Goetz brian.goetz at
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 
right now.

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(),
> 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:
> although I'm not sure that counts as precedent yet.
> Stephen

More information about the lambda-dev mailing list