commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [Math] What's the problem with interfaces?
Date Wed, 30 Mar 2011 01:19:51 GMT
Hi Gilles,

Gilles Sadowski wrote:

> Hi.
>> We have been talking about moving away from interfaces as the
>> preferred way to support people plugging in alternative
>> implementations because they have in several places gotten "behind"
>> due to the fact that adding anything to them breaks compatibility.
>> We should probably continue that discussion in a different thread.
> [This is the different thread.]
> From comments that were posted to the other thread, I gather the main
> trend that, because some interfaces needed an upgrade, the "interface"
> design tool is becoming "evil". Did I get this right?
> I guess that you refer to "RandomData" and "RandomDataImpl". This is
> indeed the typical example of abusing the "interface" tool. When only one
> implementation is meaningful, an "interface" need not be defined.

No. It is about adding something to the interface, just like Phil said. If 
you add a method to an abstract class, the dervied ones are still binary 
compatible, the same does not apply for interfaces.

We had discussions in *length* about this and I am not interested in 
starting over again.

> The "interface" is not the way (preferred or not) to support alternative
> implementations. As was already said, this is done with (abstract or not)
> classes which an alternative implementation can inherit from.
> Rather, the (Java) "interface" is supposed to represent the abstraction
> (from the "real" world object) of everything that is needed to interact
> with that object (i.e. its interface). It makes it possible to treat
> different objects on a equal footing (from the caller's point-of-view).
> But you all know that...
> So what's the problem? Is it the binary compatibility, again? This is a
> configuration management issue. When the compatibility is broken, you
> change the major version number and/or the base package name. That was
> settled, or not?

The point is that an interface should not be changed for a long time. 
Otherwise every new release is a major one.

> It would be a pity to sacrifice a tool aimed at improving the design
> because of such considerations as keeping backward compatibility with
> versions that nobody here is going to support.

It's a pity for the user, because he will *never* be able to use the next 
version as drop in.

> If some user is happy with version "M.m", he can use it forever. If he
> wants to use a newer version "N.n", he should not expect it to be
> compatible. It does not have to be! Non-compatible modifications are not
> performed out of some urge for change but stem from the desire to get a
> better product, bits by bits.

If that were true, you would currently have 10 different commons-lang, 10 
different commons-collections and so on in your classpath.

> Yes, it's not easy to get the interfaces right; so what? If you find that
> you can improve the design, you do it and bump the major verion number.
> As someone pointed out, it's not as if we'll run out of numbers.

And people will stop using it, because they are annoyed when they are 
depending in the end on n different versions of math, simply because of 
transitive dependencies.

> Part of the real problem (as shown by the amazing amount of done and
> undone work for 2.2) is that you (collectively) want to do too many things
> at the same time (lots of changes *and* few releases). To be clear, the
> problem is not the "lots of changes" part (which you would like to "solve"
> by vetoing future compatibility-breaking improvements). Note that the
> following is not a criticism of CM (which has many features etc.) but some
> of the code that I've seen (in the parts which I've more closely looked
> at) do not make me think that it is mature enough that one can say "That's
> it!" and stick with the design forever.
> Again, all this (e.g. removing duplicate code and refactoring the design)
> can be considered unimportant and swept under the carpet but IMO *any*
> cleanup is good as it will contribute to the overall robustness and
> maintainability.
> Half-baked design will continue to itch.

Half-baked upgrade strategies also.

- Jörg

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

View raw message