Static Imports vs. Standard Imports and System.out

It seems there are two different imports that I haven't spent too much time with, yet.

The first being a Standard Import, looks something like:



The second being a Static Import, looks something like:



This really is just something new I've stumbled upon and decided to read about, thought I would share what I learned here and to see if anybody has any extra ideas on the topic of Standard vs. Static Imports.

It seems like Static imports take advantage of allowing you to import Static fields and methods from a class. This means that when you type things like, System.out.println("Hello World!"), you will not have to type System every single time, if you use a Static import.

For example, using a Static import of the System class using a wildcard will look something like this:



It's pretty nice not to have to use System every time I want to print out. I was trying to find a way to make it so all I had to do was type println instead of out.println, but quickly remembered that out is a constant and might not work.

So, any drawbacks to using this Static import? Also, are there any other classes like System that are composed of all Static members that I can use? Let's see what you Ranchers have got in store for me! ;)

Well,

I've never used these static imports myself. What I do when I need to use
System.out.println a lot, is to define a method 'a' as follows:

That will keep my println's to an absolute minimum of typing.

Greetz,
Piet

Hey now, that's pretty slick there, Piet. I will definitely make use of that if my fingers ever start bleeding from using System.out.println("Ow, my Fingers!") over and over again!

I like both methods, though! Using a Static import and using the new method for printing are both pretty neat'o. I suppose a benefit from using the Static import rather than using the custom print method is that I might be using more methods that also depend on System. Something like:



Notice I don't have to stick System in front of everything from the class System. Pretty handy if you're running through a bunch of methods from System. What do ya' think?

A question actually came up in this code for me. I learned the line System.getProperties().list(System.out) from the current Java book I'm reading. I do not understand why this line works.
We are using the System classes' getProperties() method which returns a Properties object, that properties object is then used to call the Properties classes' list(PrintStream out) method. What doesn't make sense to me is how does the program know what this returned Properties object is?
The Properties type is in the java.util package which I have not imported, so since the Properties type isn't around how does the program know about it at all?

Hi Skye,

Static imports are not something you generally use. They make your code hard to read, hard to maintain and very confusing. You can quickly run into compilation problems due to ambiguous static member calls.

For example:

Am I checking to make sure d's value is less than the maximum value possible in a Float, or am I checking it against the maximum value possible in an Integer? I don't know. Either does the compiler, so it won't compile. Remember, if you are writing production code, that code could be extended into derived classes, updated and maintained by others. All of whom will need to understand and deal with the static imports.

From the Oracle Java 8 Tech notes:

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. If you overuse the static import feature, it can make your program unreadable and unmaintainable, polluting its namespace with all the static members you import. Readers of your code (including you, a few months after you wrote it) will not know which class a static member comes from. Importing all of the static members from a class can be particularly harmful to readability; if you need only one or two members, import them individually. Used appropriately, static import can make your program more readable, by removing the boilerplate of repetition of class names.

Basically, what that says is something like import static java.lang.Math.PI; might be OK if I needed to use that static constant over and over and over, but you would never want to use a wildcard static import. For that matter, wildcards shouldn't be used for non-static imports either. While the compiler is smart enough to know which classes are necessary, and only import those classes (keeping the class from being bloated), anyone reading your code won't. It's better to explicitly state the imports required so that anyone reviewing can quickly tell that this class needs java.util.Arrays and java.util.GregorianCalendar, versus having to read through the entire code file to clarify what in java.util.* is being used.

Regarding your followup question, the System class imports java.util.Properties, therefore it knows what a Properties object is and can return that type of object.

Cheers!
Chris

Piet: do you have to overload that method as System.out.println is overloaded?
Skye: the names for different kinds of import are to be found in the Java Language Specification. I suspect you will find most experienced people prefer single type imports to on demand imports.

In NetBeans you can type "sout"and hit tab and it will expand to "System.out.println". I'm sure Eclipse or your favorite IDE has some similar feature.

The only place I have ever used static imports is in unit tests when using frameworks such as Junit, Hamcrest and Mockito. These libraries are designed to form something close to natural language to make the test easy to understand, but as others have mentioned it would become prone to ambiguity and difficulty reading the code if it was used too much. I really hate it when I'm reading C/C++ source code and a method is called with no easy way to find out where it's defined because it was imported from a header file elsewhere. Java is (imho) much easier to follow (especially when you're outside of an IDE).

I use static imports when using a few (or a lot) of constants from a specific file. I don't find static imports to be evil as long as they are used appropriately. Having static imports from a dozen different classes would be confusing.

Jeanne Boyarsky wrote:I use static imports when using a few (or a lot) of constants from a specific file. I don't find static imports to be evil as long as they are used appropriately. Having static imports from a dozen different classes would be confusing.

I think perhaps 10 or more years ago when I was still using CRT monitors and when IDE's weren't quite as helpful then I would probably use static imports a lot more. But with widescreen monitors and tab-completion it's actually now more effort to add the static import in.

About System.out, I rarely use it anyway. I usually use slf4j in my projects, and then I just write LOG.debug("message").

J. Kevin Robbins wrote:In NetBeans you can type "sout"and hit tab and it will expand to "System.out.println". I'm sure Eclipse or your favorite IDE has some similar feature.

In Eclipse: "sysout", Ctrl+Space

Very good feedback, from you all! Best thing about this is that I will never forget what a Static import is used for and what problems it may cause. Thanks, Ranchers!