How does The JDK's Logger compare to Apache log4j?
Which one is better for new projects that target Java 6? How do they compare in terms of flexibility and configurability?
Best Answer
To my mind the only thing the JDK Logger has going for it is that it is part of the JDK, so it doesn't add an external dependency. If the choice is only between those two, I'd go with Log4j. It still has better support in terms of appenders, the number of people who know it (in my anecdotal observations), and a better API (that is subjective as well).
Starting a project today, the most tempting thing to do is go with slf4j and deffer the decision - you can always plug in a different framework underneath slf4j by just changing the classpath.
That being said there are other options (such as Log5j) that take advantage of the latest Java language features. I'd recommend taking a long look Logback (from one of the main programmers of Log4j, as is slf4j).
There are actually many good reasons to consider using accessors rather than directly exposing fields of a class - beyond just the argument of encapsulation and making future changes easier.
Here are the some of the reasons I am aware of:
Encapsulation of behavior associated with getting or setting the property - this allows additional functionality (like validation) to be added more easily later.
Hiding the internal representation of the property while exposing a property using an alternative representation.
Insulating your public interface from change - allowing the public interface to remain constant while the implementation changes without affecting existing consumers.
Controlling the lifetime and memory management (disposal) semantics of the property - particularly important in non-managed memory environments (like C++ or Objective-C).
Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
Improved interoperability with libraries that are designed to operate against property getter/setters - Mocking, Serialization, and WPF come to mind.
Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
Allowing the getter/setter to be passed around as lambda expressions rather than values.
Getters and setters can allow different access levels - for example the get may be public, but the set could be protected.
Best Answer
To my mind the only thing the JDK Logger has going for it is that it is part of the JDK, so it doesn't add an external dependency. If the choice is only between those two, I'd go with Log4j. It still has better support in terms of appenders, the number of people who know it (in my anecdotal observations), and a better API (that is subjective as well).
Starting a project today, the most tempting thing to do is go with slf4j and deffer the decision - you can always plug in a different framework underneath slf4j by just changing the classpath.
That being said there are other options (such as Log5j) that take advantage of the latest Java language features. I'd recommend taking a long look Logback (from one of the main programmers of Log4j, as is slf4j).