Auto inferred static imports

Stephen Colebourne scolebourne at
Wed Feb 6 16:52:02 PST 2013

I know this is too late, and its probably already been considered, but
I haven't seen it mentioned anywhere. And it might trigger a

Project Lambda appears to be defining a lot of helper static methods
to go with the Stream API. Such as the Collectors class

I'm assuming that the plan is to remove the static utility class and
move the methods to the Collector interface (once the verifier is

The use of code like this results in a need for lots of
interface-qualified prefixing, or static imports

 someStreamThing.collect( Collectors.groupingBy(...) )
 someStreamThing.collect( groupingBy(...) )   // using a static import

We also have a similar design pattern in JSR-310 on TemporalAdjuster
and TemporalQuery.

It seems that "it would be nice" if the language could do this for us.
Specifically, any static method on a functional interface (or maybe
only @FunctionalInterface) is available for use at any call site that
is target typed to that interface without any need for an explicit
static import.

 someStreamThing.collect( groupingBy(...) )   // no need for a static import

(no static import needed, because the method collect(Collector) takes
a Collector, and the static method is on Collector.

Of course an IDE can eliminate much of this pain anyway, so maybe its
no big deal and not worth a language chaneg. But it does seem like a
potentially useful extension to lambdas/Java. And perhaps it might
stimulate another related idea. Since its too late for JDK 1.8, the
only point I can suggest is a brief check to see if some other
decision has made this an impossible feature.


More information about the lambda-dev mailing list