Mark Needham

Thoughts on Software Development

My dislike of Java’s static import

with 10 comments

While playing around with JBehave I was reminded of my dislike of the import static feature which was introduced in Java 1.5.

Using import static allows us to access static members defined in another class without referencing the class name. For example suppose we want to use the following method in our code:


Normally we would need to include the class name (Math) that the static function (max) belongs to. By using the import static we can reference max like so:

import static java.lang.Math.max;

The benefit of this approach is that it makes the code read more fluently but the disadvantage is that you can’t immediately tell where a method lives. I want to be able to tell what is going on in the code from looking at it and anything which prevents this is a hindrance.

The official documentation even suggests using this functionality sparingly:

So when should you use static import? Very sparingly! Only use it when you’d otherwise be tempted to declare local copies of constants, or to abuse inheritance (the Constant Interface Antipattern). In other words, use it when you require frequent access to static members from one or two classes.

On my last project we ended up saying that import static was allowed in test code because there were relatively few places the static methods could be imported from, but when it came to production code the fully qualified path was required.

Be Sociable, Share!

Written by Mark Needham

September 24th, 2008 at 11:59 pm

Posted in Java

Tagged with , ,

  • In that case you should maybe dislike programming languages because with any of them I can do horrible things.

    I think you should blame developers that use static imports in the wrong way, not the static imports itself.

    Static imports rocks when youre creating internal DSLs.

    A great power comes with a big responsibility 🙂

  • Thomas Marti

    I concur with Diego. Also, quite a few libraries would be practically useless without that feature.
    and others…

  • Mark, static imports are just another small (and enabling!) feature – when it comes to trying to figure out where code is coming from, especially in Java, where IDEs are incredibly powerful, hovering the mouse pointer over or ctrl-clicking the method call should take care of things.

    Speaking of Java 5 features, I’d be more worried about the misuses of generics and the copious amount of needless warnings it generates – so many, in fact, there are annotations to stop them from appearing 🙂

  • Maybe my dislike is more around the misuse of them as you guys all mention – the code base I saw them used in was gathering static imports from across four different classes into one place so it wasn’t obvious at all where the original definitions of them was.

    I can certainly see some cases where they would be useful in making the code more readable but I’m not convinced for example of the benefit of statically importing say junit assertions so you can do assertEquals rather than Assert.assertEquals for example but that’s just me 🙂

    Regarding the power of some features in programming languages I agree there are some features which can be severely misused. Sometimes I wonder whether the benefits are worth the potential misuse.

  • Nate

    “I want to be able to tell what is going on in the code from looking at it and anything which prevents this is a hindrance.”

    I agree. That is the benefit of static imports. Specifically, I want the max of 1 and 2. How do I find this out? max(1,2). Sweet. I have very little need to know that this comes from java.lang.Math, and so putting Math.max(1,2) introduces noise. Much like you (hopefully) wouldn’t put java.lang.Math.max(1,2).

    The rule is simple (and somewhat subjective… if you aren’t sure, just ask me what I prefer. 🙂 ) — if it helps the code to communicate better (especially contextually!) then use it.

  • Pingback: Easily misused language features at Mark Needham()

  • Just remembered the other reason we had a problem with it – we were using eclipse’s Ivy plugin and quite frequently it wouldn’t resolve dependencies correctly.

    I think eclipse was setup to automatically clean up the imports on files or something like that so whenever the Ivy resolution failed all the import statics were being removed and we had problems trying to work out where they had come from in the first place.

    Can’t blame that all on import static of course but it was an additional problem we could have done without!

  • Pingback: Are Static Imports Becoming Increasingly Accepted in Java? | Java Code Geeks()

  • Some guy

    Why is Math.max(1,2) ok? You’re not telling me where Math came from. Shouldn’t it be java.lang.Math.max(1,2)? Seriously, A glance at the imports tells you all you need to know. The readability problem isn’t because a single short handed method is hard to read. It’s meant to be used sparingly because of the higher chance of a name collision between two methods with the same name that are actually intended to accomplish different things. That’s what’s confusing to look at. You solve it the same way you solve having two guys named John in your office. You start using their last names.

  • Some guy

    For example valueOf() could be a nasty static import. Is it making a String? An Integer? If the context it’s used in doesn’t make it clear then sure, no to static import. But sheesh when is max(1, 2) ever anything but the greater of the two?