The founder of log4j raises some valid concerns about JSR47 in his open
article located at:
http://jakarta.apache.org/log4j/docs/critique.html
I do not support log4j becoming a
replacement for JSR47 because I think that the log4j API needs to be cleaned up
and made more user-friendly for simple logging tasks. I think that JSR47 has
made improvements in this area. However, very careful attention should be paid
to issues regarding performance, error handling, and interoperability prior to
finalizing the proposed API. Specifically:
1) More effort should be spent optimizing the specification so that it
does not become yet another Java performance burden. For example, parameters to
the logging methods in JSR47 are always evaluated. Frequently the evaluation of
these parameters results in new and expensive object allocations... which is
unnecessary when logging is disabled. The typical solution is to wrap wrap every
logging method with an if statement that determines whether logging is enabled.
This is inconvenient and will therefore be difficult to enforce in practice. I
suggest investigating ways to perform conditional evaluation of parameters,
perhaps borrowing from work done for the assertion facility in JSR41.
2) The addition of logging should not
affect an application's behavior (i.e. it should not introduce new Errors or
Exceptions).
3) I'd like to see more
focused collaboration between JSR47 and the J2EE community. There is an active
and unresolved discussion about how to achieve high-performance J2EE-compliant
debugging. I'm not sure that JSR47 in its current form addresses this
issue.
Piper