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.erras 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.erroccassionally 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.outvery 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.outstatically can feel right at home. One of the implicit variables that web containers support for JSPs is the
outvariable. This implicit
outvariable (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.outalso allows the
outto 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
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.outcouple 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.
In general, I agree with the "Static Import" portion of the Java Programming Language J2SE 5 New Features and Enhancements documentation which states:
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
⇒ StackOverflow: What Is a Good Use Case for Static Import of Methods?
⇒ My Dislike of Java's Static Import Feature
⇒ Use Static Imports Rarely
⇒ Do You Like Static Imports?