Re: [logging] getChildLogger Patch submitted to bugzilla issue #36062

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Tue, 2005-10-11 at 23:16 +0200, Joerg Hohwiller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> robert burrell donkin wrote:
> > On Sun, 2005-10-09 at 21:20 +0200, Joerg Hohwiller wrote:
> > 
> >>-----BEGIN PGP SIGNED MESSAGE-----

<snip>

> >>>6 bit unsure about fitting a superclass (AbstractLogger) just to provide
> >>>a utility method. sometimes this can prove harmful in the long run since
> >>>it may limit inheritance options for the future. can't think of any
> >>>reason why this would apply in this case right now, though.
> >>
> >>The reason is NOT just to provide a utility method. It is to have the ability to
> >>add a method to the "Logger" interface later without breaking compatibility.
> > 
> > 
> > not sure i understand this correctly. so long as Logger is an interface,
> > methods cannot be added without breaking compatibility. in order to be
> > able to add new methods, the Logger logical interface would need to be
> > implementated as an abstract class.
> You are right with what you are saying. To make it clear what I meant.
> If someone is directly implementing the Logger interface and not extending
> AbstractLogger even though suggested, he will have no guarantee for
> compatibility. I do not know if this is acceptable. As I pointed out,
> the big issue for me is, if one day guys from log4j or whatever decide to
> directly implement the JCL API.
> But the suggestion in javadoc is at least reducing the harm about compatibility
> while not giving up the flexibility of an interface.

i think that there are two different issues here. 

i agree that the proposal satisfies implementation compatibility. (in
other words, it's not unreasonable to ask a Log implementor to extend
AbstractLogger.) however, this group is tiny constituency. my main
concern is for JCL users.

once an interface is published, it cannot be changed without breaking
backwards compatibility. if Logger changes then every bit of code that
uses that interface must be recompiled. 

for an application, this isn't a major problem. for a shallow library
(typically used directly by applications) this is an issue but such a
huge one. but for a deep library used by libraries, breaking backwards
compatibility is a very major issue since every version of every library
would need recompiling to be compatible. 

IMO JCL is now so widely used that braking compatibility is unthinkable.
so it must be assumed that any new interfaces are immutable. 

it is therefore usual for deep libraries to prefer to model logical
interfaces as abstract classes: trading flexibility for compatibility. 

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org