Auto inferred static imports

Pablo Grisafi pablogrisafi1975 at
Thu Feb 7 11:46:20 PST 2013

I always thought about something like that for enums ...automatic
import for enums only in method calls.
if I have enum Color{ BLUE, RED}
and a method void paint(Color color) in any class
I think it would be nice to make calls
paint(BLUE) instead of paint(Color.BLUE)
compiler can infer the "Color." part, and user can read the code in a
more natural way...sometimes.
I like it because it does not pollute the namespace...but I don't
think we will see that anytime.

> ---------- Forwarded message ----------
> From: Stephen Colebourne <scolebourne at>
> To: lambda-dev <lambda-dev at>
> Cc:
> Date: Thu, 7 Feb 2013 00:52:02 +0000
> Subject: Auto inferred static imports
> 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
> thought...
> 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
> fixed).
> 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.
> <maybe-nice-to-have-language-feature>
> 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.
> </maybe-nice-to-have-language-feature>
> Stephen

More information about the lambda-dev mailing list