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)?
Don't you like java.util.logging.Logger? It is included into JDK, you don't need anything else.
Nothing's more lightweight than using java.util.logging.Logger, since it's already available in the JRE.
You ask three questions:
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.
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.
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.
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.
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.
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.