Monday, August 24, 2009

Static Imports and System.out

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.out or 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.out and 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.out and 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 @Inheritance(strategy=InheritanceType.SINGLE_TABLE).

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 out for 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.

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.


Conclusion

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?

No comments: