Hi,
Backwards compatibility is very important to the RDF4J project.
Currently we are very strict. Any change of method signature or return type is considered non backwards compatible. Any removal of a class, method or field is also not backwards compatible. Of course limited to public things.
We also don't allow for methods to be added to public interfaces.
This last point is something I would like to discuss a bit.
What I have done currently is to add default methods to interfaces and then override them in our own code. This means that anyone who uses those interfaces will get default implementations, usually no-ops, and don't notice anything. Then when we release a major version we would remove these default implementations.
I'm not sure if I really like this, but I am thinking that we should look into how to formalise this so that we remember to remove the default implementations when it comes to for a major release.
Well, one thing we could do to keep track is log a general "clean up" issue for the next major release and add these new methods to a list there.
However: why bother? What do we gain by removing these default methods in a major release? They are typically just one or two lines (either a no-op or throwing an UnsupportedOperationException) and if they're not in anybody's way... To some extent that even holds for deprecated code, which is why we try to be conservative with removing that, too.
Also, for what it's worth: I've not found it necessary to extend existing interfaces very often. Usually there are alternative design choices that preserve compatibility better, such as a completely new interface, or a public utility class. That's not to say it never happens of course (the new getStatements in Model is a recent example), but it doesn't seem to me to be a very common thing.
Is there a specific example you have in mind that brought this up?
Another option would be to say that we do not extend semantic versioning to imply that public interfaces can not grow. We would then be able to add methods to interfaces in minor versions.
I think that's not something we can get away with. Whichever way you turn it, "backward compatibility" means that a new version works without having to adapt existing code, and excluding public interface extensions would break that. I also don't see the need as we can very easily keep compatibility by the methods we discussed above. I kind of see the argument of distinguishing between interfaces that are intended to be implemented by third parties vs interfaces that we only expose to use, but do not expect third parties to provide their own implementations of. Unfortunately, I don't think making that distinction is a common thing in the Java world, and I wouldn't know how to communicate in a way that wouldn't confuse the heck out of people.
Perhaps instead we should start looking at the Java 9 module mechanism again, to make it more explicit what interfaces and classes are in our public api, and which ones are internal. OF course, since we have to stay Java 8 compatible for now, we can't rely on automatic enforcement, but we could at least use it as a documenting feature, perhaps.
Jeen
