BackwardsCompatibility - Lucene-java Wiki Or, how to introduce new methods to Interfaces
BackwardsCompatibility - Lucene-java Wiki
Hmmm, so I have been pondering this for a while and don’t quite know a good solution… So help would be appreciated.
As an active developer of Lucene, we have pretty strict rules about Backwards Compatibility, as evidenced by the link given above. For the most part, what this translates to, is the need to use Abstract base classes in Java, instead of Interfaces, since adding methods to interfaces in libraries quickly causes downstream, unknown implementations to instantly be broken, whereas adding them to abstract classes does not b/c we can give a default implementation.
On the one hand, one might say to the user of the library, don’t upgrade unless you are prepared to handle the new code. Naturally, the user’s pushback is, don’t break my code for minor releases. This leads to having lots of deprecated methods and other gyrations to work around the backwards compatibility requirements. For the most part, it isn’t a big deal once you adjust your thinking from the application developer mindset to the library developer mindset, yet I can’t help but wonder if there isn’t a better way. Granted, I am not saying I know what it is, but just like @deprecated tells everyone a method or class is going away, I wish there was a way to tell everyone, via code, that new methods are coming. Not sure what the semantics of this are, but for an Interface, I was thinking maybe you could introduce something like an @introducing annotation. The interface would still work as is, but it lets the user know by some future version that this interface is going to change by giving a compiler warning and then, when the new version is met, it does break implementations.
Then, I think, one could provide both an Interface and an abstract base class implementation of the interface, which I often think is the best of both worlds. This way, one can have the benefits of multiple implementations of the interface and the library can provide a basic implementation.
Am I crazy? Does something like this exist in other languages? Not sure what the right answer is here, but I do know I would like an effective way of communicating to Lucene’s users that an Interface is going to change, since Users really like interfaces and library developers really like abstract base classes and sometimes it feels like we never will meet.
