On Apr 20, 2006, at 3:05 PM, Boris Unckel wrote:
Hello Lyall,
Pearce, Lyall wrote:
I am unsure if this is more a user or developer question, I will lean
towards developer unless told otherwise.
log4j1.3-alpha8 has a nice class TimeBasedRollingPolicy
(http://logging.apache.org/log4j/docs/api-1.3/org/apache/log4j/
rolling/T
imeBasedRollingPolicy.html)
The Primary question: Why are the classes marked final? Why can't I
extend a log4j class?
I am not a log4j developer. I have seen the discussions about
compatibility on this list for the development of log4j 1.3
and the enormous efforts spend on compatibility.
It is very hard to change the internal implementation of an class
if lots of people are extending it and relying on a specific
behaviour.
If you want to have your homegrown XYZPolicy: Copy the code,
implement the interface and use it.
If log4j developers want to change something, they just have to
care that the interface is not broken, but they can
change the other class without braking anyones code.
Regards
Boris
That is the reason that new stuff is generally marked final. For a
more complete discussion see "Item 15: Design or document for
inheritance or prohibit it" in "Effective Java".
If there is a compelling reason that something should be open for
extension, then it is always possible to drop the final qualifier,
however it is impossible to put final on a class without
compatibility issues. The default behavior now is to tightly
constrain new code and loosen it up if and when compelling use cases
are presented.
Instead of copying code, your implementation of the interface could
delegate to an instance of TimeBasedRollingPolicy. For a discussion
on that, see "Item 14: Favor composition over inheritance".
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
