[slf4j-dev] updated 2.0 proposal

[John Vasileff]

On Sep 17, 2011, at 4:32 PM, Joern Huxhorn wrote:

...
> Extending an interface can not be done in a binary-compatible way (at least not until jdk8 with extension methods, see http://www.javarants.com/2011/01/22/using-closures-method-handles-and-extension-methods-in-java-8-jsr-335/ ) simply because all outside implementations of the interface will go boom because they don't implement the new methods.
> 
> That's one of the reasons why I suggested moving over to a fresh interface. This enables us to remove superfluous methods like the ones with one or two arguments while also extending it at other places, like Message support. This is also the way people are doing it in other projects, for example JUnit and commons-lang.

But extending the interface while maintaining binary compatibility is exactly what I have done. Give it a try!  In my testing, using new interface methods on 1.6.0 adapters from maven central works great.  The technique I used isn't a general solution for things like say, the jdbc interfaces that keep evolving.  But it works well for slf4j and promises to allow both long term compatibility while not preventing innovation.

This both avoids and prevents issues like the 1.5 -> 1.6 update that broke compatibility due to a change in LocationAwareLogger.

> 
> It's not only people that are too lazy to update their Java installation. Some are simply forced to use old versions (I remember someone needed to work on AS/400). Those could still use the old API without being cut off from fixes.
> 
> Having two interfaces isn't more confusing than the old and new junit packages. People that don't care can just stay on the old interface without any work on their side while people that do care can switch to the new interface if they like.
> 
...
> Joern.


John