Java custom logger: logging standards or/and best practices

Question

I am developing a framework and I won't the jar to be light weight and independent as much as it can be.

So I wrote my logging class:

import java.util.Date;
import java.util.Properties;

public class Logger {

 private static final Logger me = new Logger();

 private static boolean info = false;
 private static boolean debug = false;
 private static boolean error = false;

 private static String className = null;

 public static Logger getInstance(Class<?> clazz) { 
  className = clazz.getCanonicalName();
  try {
   Properties props = new CustProps().load(clazz);
   if(props.get(CustProps.NAME_LOG_MODE) != null) {
    String devMode = props.getProperty(CustProps.NAME_LOG_MODE).toLowerCase();
    if("info".equals(devMode)) {
     info = true;
     debug = true;
    } else if("debug".equals(devMode)) {
     debug = true;
    } 
   }
  } catch (Exception e) {
   // debug is error by default
  }

  error = true;

  return me;
 }

 public void logError(Object msg) {
  if(isError()) {
   System.out.println(new Date().toString()+ " ERROR ["+Logger.className+"] - " + msg);
  }
 }

 public void logDebug(Object msg) {
  if(isDebug()) {
   System.out.println(new Date().toString()+ " DEBUG ["+Logger.className+"] - " + msg);
  }
 }

 public void logInfo(Object msg) {
  if(isInfo()) {
   System.out.println(new Date().toString()+ " INFO ["+Logger.className+"] - " + msg);
  }
 }


 public boolean isInfo() {
  return Logger.info;
 }

 public boolean isDebug() {
  return Logger.debug;
 }

 public boolean isError() {
  return Logger.error;
 }
}

What are best practices to make this logging better? Is making your own logger even worth it? Will the use of this logger make my framework worse than choosing something existing (like log4j)?

Answer 1

Don't you like java.util.logging.Logger? It is included into JDK, you don't need anything else.

Answer 2

Why re-invent the wheel?

If you use the Java util logging library then it's already in the JDK and so you have no extra code to provide.

Otherwise, log4j is surely pretty good.

Answer 3

Use log4j. It is not a heavy weight logging framework, what do you mean by "independent as much as it can be"?
Just add the log4j jar to your framework and you are good to go.

Answer 4

Nothing's more lightweight than using java.util.logging.Logger, since it's already available in the JRE.

Answer 5

I would STRONGLY recommend that you use slf4j as your logging API, as it is designed to be able to switch backends at deployment time. In other words, if you ever outgrow your own logging framework or has to interface with others using something else, it is simple to change your mind.

http://slf4j.org/

It also allows you to use the {}-construction for easy inserting objects in your log strings without overhead if that string is not actually logged anyway.

I'll suggest you consider adapting the "Simple" backend to your needs since it probably provides 90% of what you want.

http://www.slf4j.org/apidocs/org/slf4j/impl/SimpleLogger.html

Note: Do not use any backend directly (like log4j or java.util.logging) as it will essentially lock your code to that backend. Use a facade.

Answer 6

I would agree with the other comments - use a COTS tool (either Logger, Log4j or other). Writing and maintaining your own is (usually) not worth it.

One more point to consider: If your framework contains other 3rd party software that you'd like integrated into one log file, you'd have to use some shared tool (e.g. the one supported by that 3rd party software). It is often very helpful to have all pieces of the system consolidate logs into one place.

Answer 7

You ask three questions:

• What are best practices to make this logging better?
  

As others have noted, the best practice would be to replace it entirely, either with something like log4j or slf4j, or, to meet your "independence" goal, simply with java.util.Logger.

• Is making your own logger even worth it?

No, except in very specialized circumstances, where for some reason, the existing frameworks don't meet your needs. You've said nothing to indicate that that might be the case.

• Will the use of this logger make my framework worse than choosing something existing (like log4j)?

Yes, if for no other reason than that it will make other maintainers spend a few minutes reading your logging class when they come into your codebase. Using an existing framework means they already know what it does.