commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] detecting logging libs
Date Wed, 25 May 2005 20:00:24 GMT
On Tue, 2005-05-24 at 11:09 +1200, Simon Kitching wrote:
> 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".

yep

> 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.

it's hard to see how any major improvement in the LogFactoryImpl
discovery code could be possible whilst maintaining full compatibility.

(this is one of the reasons why richard advocated allowing users to use
commons-discovery and developing that instead. the DON_QUIXOTE branch
illustrates one way that JCL could allow other discovery methods without
breaking compatibility.)

> 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...

that's pretty much how i see it

semantic changes require (at least) a minor version change (rather than
a release). given the version protocol here in the commons, subclassers
really need to read the release notes for any minor or major version
change, and rewrite their classes where necessary. (this is problem that
often confronts frameworks. one solution often adopted is to indicate in
the java docs which are public API elements and so will not be changed
without a major version revision.)

- robert


---------------------------------------------------------------------
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