Employing a logging framework?

[mccartney]

Currently the code is full of System.out.println statements. Some/most of them being commented out, some of them not.

The industry standard practice is to employ a logging framework (log4j, commons-logging, java.util.logging) instead, so that:

• people can control in runtime what is displayed and what is not
• people can direct the output not only to stdout, but to the target of their source (e.g. to disk, to a log aggregation tool)
• etc.

Currently using the library makes derived programs print out something to stdout and people have no control of that.

[mccartney]

@timmolter what's your view on this?

[timmolter]

I leaned against it in the beginning as a design decision. There shouldn't be any souts that aren't commented out except for debugging and testing. I'd rather not not have to add the extra dependency. What really is of interest in a charting lib to be logged?

[mccartney]

As of now, in xchart/src/main there are:

• 190 commented out System.out.println statements (find -name *.java -exec grep -H "System.out.println" {} \; | grep "//")
• 11 not commented out ones (find -name *.java -exec grep -H "System.out.println" {} \; | grep -v "//")

What really is of interest in a charting lib to be logged? I see one area - i.e. for people troubleshooting or contributing to the library when they try to understand how the library behaves.

I see several options:

1. Leave it like it is.
2. Remove all the System.out.println statements, commented or not
3. Change the System.out.println statements to usages java.util.logging.Logger, most likely calls to its .fine() or similar
4. Introduce an in-house mini framework for logging - i.e. a singleton DebugOutput similar to:

   class DebugOutput {
   private static final boolean PRINT = false;
   public static void print(String message) {
    if (PRINT) System.out.println(message);
   }
   }

5. Adapt log4j or another proper log-management framework.

As to my comments:

• I bet there's some value in these statements, so (2) is probably not what anyone prefers.
• (3) is not an extra dependency
• (3) and (4) are quite similar; (3) has some minor advantages over (4) - extra features
• (5) is something you don't like (which I get totally)
• The biggest advantage of (5) or (3) over the other options is that people can turn on this debug output without rebuilding the library, even in runtime after the program has started.

[wborn]

Adapt log4j or another proper log-management framework.

Rather use a logging facade like SLF4J which would allow everyone to use their favorite logging framework. It is very common to use SLF4J nowadays and only adds one extra dependency (slf4j-api, ~42kB) that has no other dependencies. Even that dependency could be made optional by wrapping the calls, catching ClassNotFoundException when it occurs and then ignore further log calls... or use the System.out.println method if some System.getProperty variable is set.

[mccartney]

Here's some code with System.out.printlns: https://github.com/knowm/XChart/blob/1f31cce168b26adbec479eb4f38d7c6cd9724a53/xchart/src/main/java/org/knowm/xchart/internal/chartpart/AxisTickCalculator_.java#L302-L311

[mccartney]

slf4j(-api) is the industry standard these days

[timmolter]

and System.out.printlns should be commented out before a release. slf4j would be the way to go for sure if we needed a logging framework for this project. But do we really? I have slf4j in all my other OSS projects but it doesn't make sense really to me for this one. The commented out System.out.printlns are for debugging/developing the code, at least the ones I wrote.