lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: Fieldable, AbstractField, Field
Date Wed, 19 Mar 2008 17:03:00 GMT
Chris Hostetter wrote:
> Committers tend to prefer abstract classes for extension points because it 
> makes it easier to support backwards compatibility in the cases were we 
> want to add methods to extendable APIs and the "default" behavior for 
> these new methods is simple (or obvious delegation to existing methods) 
> so that people who have writen custom impls can upgrade easily without 
> needing to invest time in making changes.  

Yes, this is a huge problem with interfaces.  We struggle with it in 
Hadoop, where interfaces were used extensively and keep us from 
improving core APIs in much-needed ways.  In the end we'll end up 
replacing them with abstract classes in a new package.

> But abstract classes can be harder to mock when doing mock testing, and 
> some developers would prefer interfaces that they can implement with 
> their existing classes -- i suspect these people who would prefer 
> interfaces are willing to invest the time to make changes to their impls 
> when upgrading lucene if the interfaces were to change.

These problems seem more easily surmountable.  It should be no harder to 
implement a mock version of an abstract class than an interface.  And 
developers are not much burdened by being unable to use a single class 
for many things.

> Perhaps the solution is a middle ground: altering our APIs such that all 
> extension points we advertise have both an abstract base class as well as 
> an interface and all methods that take them as arguments use the interface 
> name. then we relax our backcompat commitments 
> such that we garuntee between minor releases that the interfaces won't 
> change unless the corrisponding abstract base class changes to acocunt 
> for it ... so if customers subclass the base class their code will 
> continue to work, but if they implement the interface directly ignoring 
> the base class they are on their own to ensure their code compiles against 
> future minor versions.

It will be hard to enforce this.  Applications will implement the 
interfaces and will be broken by changes to them and folks will 
complain, generating lengthy, non-productive incompatibility flamewars.

After 10 years of Java programming, I find that interfaces are rarely 
worth the trouble they create.  They're handy for single-method things 
that never change, like Comparable, Runnable, and Cloneable, but for any 
more complicated API that's part of an evolving system they're usually a 


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

View raw message