In Cay Horstmann‘s recent blog posting Are You Using Static Import? he asks the question, “Have you switched from System.out to out with a static import?” I found this to be an interesting question because it got me thinking about a different ways that my Java coding has changed over the years and over the different versions of Java.
My Use of System.out
I like static imports and do use them in situations that feel appropriate. However, I have only occassionally used a static import in conjunction with System.out or System.err. I realized that there are several reasons for this with the most important being that I simply don’t use
System.err as often as I used to.
In production code, I typically use a logging tool such as log4j or java.util.logging rather than using
System.err. For simple tools with command-line interfaces, I have become a big fan of the java.io.Console class. Its readLine() and printf methods are easy to use. The only downside is that it requires Java SE 6 and a console device. I still do use
System.err occassionally for simple examples and for quick and dirty debugging, but often these cases are such that it has not seemed worth the effort to statically import
System.out. Although I have not statically imported
System.out very often, I don’t think it’s a bad idea. I explore the reasons for this in the remainder of this blog posting.
Advantages of Statically Importing System.out
For a JavaServer Pages (JSP) developer, importing
System.out statically can feel right at home. One of the implicit variables that web containers support for JSPs is the
out variable. This implicit
out variable (JspWriter) can be used by the JSP author in much the same way that a statically imported
System.out (PrintStream) can be used. Statically importing
System.out also allows the
out to be used in a way that feels similar to using Groovy‘s println without needing to scope it explicitly.
There are general advantages of static imports that can make them attractive. An obvious advantage is more concise code that uses constants. I especially like to statically import classes used as parameters to Java annotations. For example, static imports allows me to use the JPA annotation
@Inheritance(strategy=SINGLE_TABLE) rather than
I prefer use of static imports in situation such as these when their use is most likely to be obvious to other developers maintaining my code. Developers familiar with the Java Persistence API (JPA) should not need the class scope on the annotation’s parameter and the context of the annotation implies the relationship of the parameter. Likewise, I believe that using
System.out couple with familiar calls like println() is conventional enough to not be a problem.
Disadvantages of Statically Importing System.out
The comments on the previously cited Cay Horstmann blog post are longer than the blog post itself. We all have opinions. I do believe there are times when static imports can cause more maintenance problems than they are worth, but I think they are beneficial and safe to use in the appropriate circumstances as described above. I don’t use static imports indiscriminately, but do think they improve readability and maintainability when used in the appropriate context.
So when should you use static import? Very sparingly! … 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. … Used appropriately, static import can make your program more readable, by removing the boilerplate of repetition of class names.
I think the above snippet, along with the more explanatory text I omitted here for brevity, does a nice job of describing appropriate use of static imports.
As with most controversial development issues, my feeling is that absolute positions such as “always use” static imports or “never use” static imports may be easier to remember, but that just a little consideration can lead to effective use of static imports for more readable and maintainable code.
Others’ Thoughts on Use of Static Imports