commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [logging] detecting logging libs
Date Mon, 23 May 2005 23:09:20 GMT
On Mon, 2005-05-23 at 22:34 +0100, robert burrell donkin wrote:
> >  * Robert, are you ok with ripping out the isXYZAvailable
> >    methods and calling the next release 1.1?
> 
> breaking binary compatibility anywhere in JCL would be a very, very big
> deal. JCL is used even more widely than commons-collections and breaking
> binary compatibility would cause even greater misery. do you really want
> to be responsible for breaking tens of thousands of applications world
> wide...?
> 
> these changes would break symantic compatibility and so these are not
> changes for a point release. a 1.1 release would be required as well as
> appropriate notices in the release notes. i strongly believe that binary
> compatibility in JCL needs to be preserved and therefore think that a
> 1.1 release containing improved discovery along these lines but
> retaining the deprecated old methods would be the best approach.  

Firstly, as I described earlier, changing the behaviour of the
LogFactoryImpl class to *not* call the XYZAvailable methods is also an
"incompatible change". It's just a *semantic* one rather than a
syntactic one that compilers can detect (that actually makes it worse in
some ways). Classes that subclass LogFactoryImpl and override those
methods would no longer work as expected, even if we kept the old
methods for "backward compatibility".

So if we want to keep complete backward compatibility in the *real*
sense (semantic as well as synactic) we are paralysed; no improvement is
possible.

But this change only affects people who *subclass* LogFactoryImpl, not
any of the code that *uses* LogFactory/Log. And given that the number of
people who *actually* subclasses LogFactoryImpl can probably be counted
on the fingers of no hands, it seems a shame to paralyse development in
order to keep compatibility with code that doesn't exist.

If we rip these methods out, and someone out there *has* for their own
bizarre reasons subclassed LogFactoryImpl, then they will at least
notice the change and fix their code. If we keep the methods but change
the class behaviour their code will just silently not work any more. Not
that I believe there *is* any such code, of course...

> 
> (as an aside: it is the presence of so many protected methods to allow
> easy subclassing which is IMHO the main flaw in JCL. the algorithms
> cannot be fixed without breaking compatibility.)

+1. 

Protected stuff is just as much part of the public API as public stuff,
and the same amount of thought needs to be given before making something
protected. And in my opinion, class fields should never be protected,
only ever private.


Regards,

Simon


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


Mime
View raw message