: This kind of usage is uncommon anywhere. Maybe ,static import pollutes I don't know about "anywhere" ... if nothing else you can see it right here in Solr :)
It's essentially the same thing as "import aliasing" or "type aliasing" as has been proposed many times by many people ... and according to at least one person from Sun i rememeber talking to, was suppose to be in java 1.6, but aparently he lied. http://www.oreillynet.com/onjava/blog/2003/06/new_static_imports_friend_of_f.html http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4478140 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4194542 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4983159 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4214789 etc... : the namesapce, but users are more used to this (because the language : recommends this). The reason for introducing static import was to : avoid this kind of clever tricks. If you are using any modern IDE , it The primary reason static import was added (per the 1.5 docs) was as an alternative to the "Constant Interface Antipattern" in which a public class implements (or extends) something that should not be part of it's API, exposing implementation details that should remain hidden DismaxQParser and RequestHandlerBase do not implement or extend anything in a way that pollutes their API. The private static "U" subclasses exist or a clear purpose, and ar not exposed as part of any API or contract. In the absence of "import aliasing" it provides a clear, short, prefix for static methods used in the outerclass, and it's clear to anyone reading the code that those method calls are *not* local, and come from somewhere else. : avoid this kind of clever tricks. If you are using any modern IDE , it : tells you whether is is static or where it belongs to. We should not make the code ambiguious just because modern IDEs can provide tools to help people disabiguiate. Particularly in an OpenSource project where we want to make sure people can easily read the code regardless of what editor/tools they use ... not to mention things like reading patches and browsing the SVN repository via HTTP. : we can do : import static foo.Foo.a; : import static foo.Foo.b; : : we must import only those methods we wish to use (to minimize pollution). If you really want to minimize the pollution, don't use a static import -- the way things are now, there is *no* pollution of the method space in the outer class, the methods are explicitly called on a utility class. If there's a concensus that method calls like "U.parseFieldBoosts(foo))" are confusing then i'm perfectly happy to replace them with "SolrPluginUtils.parseFieldBoosts(foo))" but using a static import so they are just "parseFieldBoosts(foo))" certainly isn't going to make the code less confusing. -Hoss
