Are you still using print statements for debugging?
There are more effective ways to debug your Java code
For as long as I have been programming (almost two decades now), I’ve used some form of a print statement for debugging purposes. Using print statements is a good way to trace through your code and troubleshoot potential problems. In addition, print statements can be used for logging and diagnostic purposes.
However, interactive debuggers that allow you to step through your code and inspect your program’s variables and view the stack trace have been around since the early 1980s. So it surprises me that even after all that time, many programmers still primarily use print statements to debug their code. As a Java programmer, you are probably all too familiar with the System.out.println() and System.err.println() methods. In fact, most Java programmers I know use a combination of a text editor, the JDK, and println statements to develop, debug, and deploy their applications.
Ineffective and irritating
While print statements can be useful, I have never found them to be very effective. Inspecting hundreds of output lines can be quite overwhelming, and the code itself gets cluttered with numerous lines of debugging statements. Also, if you do not capture the output to a file, you can find yourself scrolling up and down your console window only to discover that you have lost some of the output because your window’s buffer size is too small.
That scenario becomes even worse in JSP/servlet development. With standalone applications or applets, you generally know where the output of System.out and/or System.err is located — either in your console window or in the browser’s Java console. With JSP and servlets, you can probably find the output in the JSP/servlet engine’s log files, but that isn’t always the case. The JSP/servlet engine’s error output and standard output can go to different files. To make matters worse, most JSP/servlet engines allow you to configure/specify the name of the log files. If an administrator reconfigures the default location of these files, you can waste time trying to locate the files; and if you don’t have permission to access the files, you are out of luck until the problem is fixed.
Successful alternatives
Experienced developers generally use some sort of a logging/tracing framework that can send all debugging messages to one or more files. In addition, those frameworks can include various debugging levels that can be configured in the application. So for troubleshooting purposes, an application’s debugging level can be turned up (like a volume control), and more debugging and/or diagnostic messages can be generated.
Of course, even better alternatives are available in the market today, in the form of new and improved debugging tools. For example, MetaMata’s debugging solution allows you to debug JSP code. Traditional Java IDEs such as Visual Café and JBuilder allow you to step through code. In my opinion, Visual Café is one IDE that has finally gotten it right after five years in existence. Visual Café 4.0x loads much faster than its predecessors, and it is also very stable and provides powerful features such as remote EJB and JSP debugging. Those features can almost entirely eliminate the need for print statements — at least for debugging purposes — though you still might want to use them for logging.
Conclusion
Java has matured quite a bit in the past five years, and Java development tools have as well. The question is: are you one of the developers that still uses print statements for debugging? And will the new tools convince you to alter your style of debugging? Write to me and let me know. Or sound off in the iSavvix Soapbox forum.
