commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo di Lorenzo Lopes <>
Subject Re: [math] 1.1 clirr report, backward compatibility
Date Mon, 13 Jun 2005 04:36:55 GMT
So, only to put my opinion in vote terms:

+1 could break backward compatibility  in release 2.0 if necessary:

We must change the API. There are so many to improve. We cannot be 
plastered , specially now that commons math is still far from a stable 
API. But I agree with backward compatibility directions anyway.

+1 to create a most abstract interface like:

interface InterfaceFoo2 extends  InterfaceFoo1

The reasons I´ve already posted in last mail.;)

Mark Diggory wrote:

> Simon Kitching wrote:
>> On Mon, 2005-06-13 at 14:47 +1200, Simon Kitching wrote:
>>> Hi Mark,
>>> In the example below, I would regard this change as being an
>>> incompatible change anyway. Code using the new API isn't compatible 
>>> with
>>> code implementing the old API because an exception can be thrown when
>>> invoking a normal-looking method. Maybe if the new method's javadoc
>>> explicitly states that "some implementations may not support this
>>> operation and will throw an exception" but even then it feels wrong to
>>> me.
> Well, its not elegant, the exception handling establishes that there 
> is a forwards compatibility issue with the third parties 
> implementation (which they would then have to correct). Ultimately, 
> either way the third party needs to make the modification, the Stub 
> just delays this fact. Which is better, break during compilation, or 
> break during runtime? This shows a downfall in the strategy, a break 
> during compilation is more likely to be caught by the third party 
> developers and an exception is more likely to be caught by the third 
> parties "users". It'd seem better if the incompatibility were caught 
> by the developers, so in this way my example sucks. The simplest case 
> ends up the best. Just modify the Interface directly (yes, on a Major 
> release version) and let the third party developers adapt, thats 
> software evolution.
>>> There are some cases where this pattern does work, though.
>>> Commons-digester declares Rule as an abstract class rather than an
>>> interface. This allowed the begin/body/end methods to be enhanced with
>>> additional parameters, with the new methods delegating back to the old
>>> ones by default. This pattern is also described in the eclipse doc
>>> referenced by Stephen below. There isn't any interface involved, 
>>> though:
>>> an abstract class is used *in place of* an interface.
>>> In commons-digester 2.x (nowhere near release yet), Action is an
>>> interface whose javadoc declares explicitly that it may change in minor
>>> releases, and that users should subclass AbstractAction instead:

>> I should note that the reason that digester2 adopted the "interface +
>> abstract implementation" rather than the digester1 "abstract class
>> instead of interface" approach was that people pointed out:
>> * interfaces are useful for generating dynamic proxies at runtime.
>> * mock objects for unit testing are easier done on interfaces
>> Neither of these have problems associated with evolving the interface;
>> the dynamic problem of course isn't relevant and the unit tests can
>> assume to be only internal to the project and can be updated to match
>> the new release.
>> And where 99% of user code is simply *using* the API instead of
>> *implementing* the API, they can deal with the nice and traditional
>> interface. Only implementers of the API really need to care about the
>> existence of the abstract class.
> Not only this but that 1% actually implementing the API is more than 
> likely going to be lurking on your developer list and contributing to 
> its development ;-)
> IMHO, our current userbase is simply just using the API at this point 
> and will tolerate interface changes if it improves the API, it would 
> be an interesting poll to see if anyone actually implemented their own 
> Matrix classes on our interfaces and I'd be extremely surprised if it 
> had.
> -Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message