commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [configuration] Interface vs class
Date Wed, 05 Nov 2008 09:04:01 GMT
Jörg Schaible schrieb:
>>> IMHO we should define what we want to reach. Adding a
>>> method to an interface does not break *binary* compatibility
>>> of existing code. The method is simply not called. However, a
>>> client will have to implement the new method, if CConf is a
>>> compile time dependency *and* he uses an implementation not
>>> delivered by CConf. Maybe it is the best approach to have an
>>> abstract base class and the interface. We have to tell our
>>> users, that they should extend from the abstract class if
>>> they want to ensure backward compatibility for own
>>> implementations of the Configuration interface. Point is,
>>> that it *is* only an advice/recommendation and something like
>>> clirr will always report a violation in compatibility.
>>> Hoiwever, it is our desicion how we should proceed.
>>> - Jörg
>> I 'd be happy to do it this way, but I am skeptical whether such a
>> policy can actually be established. You know how hard it is
>> to convince
>> people to vote +1 for a release. If clirr claims that there
>> is a binary
>> incompatible change, chances a pretty good that you get a veto.
> Clirr is used to detect unintentional binary incompatibility. If we document the facts
(in site documentation and javadoc) everybody is informed and should not be surprised if we
actually follow this agenda. If a new version is enhancing the Configuration interface then,
the release manager should state this fact in release notes and vote call by documenting the
*expected* clirr result with a pointer to the agreement that is used as basis for the incompatibility.
IMHO this should be enough. Following either the interface or the abstract class approach
has its downside. Maybe such a combination will give you the pros of both worlds.
So the rule would be:
* the project provides both an interface and an abstract class that
implements that interface.
* code that *uses* the API should always use just the interface, ie
*call* methods via the interface and pass instances around as the
interface type
* code that *implements* the API should always subclass the base class.

The project reserves the right to add methods to the interface, but will
always provide a concrete default implementation on the abstract
subclass. Methods will *not* be added to the interface if a sensible
default implementation cannot be provided.

That sounds like a pretty good approach to me; seems to ensure maximum
backward compatibility while keeping a clean interface-based API (which
allows interface-based proxies to be generated at runtime).

I would agree with Jörg here, that as long as release-notes document
expected clirr incompatibilities there is no problem. Clirr can of
course be configured to ignore specific classes when processing...

Regards, Simon

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message