Brian McCallister: "To take a concrete example, a coworker (thanks Jax!) recently re-added first class support for callable statements to jDBI. jDBI uses a Handle interface to expose operations against a database. It has gained a method:
public <ReturnType> Call<ReturnType> createCall(String callableSql,
CallableStatementMapper<ReturnType> mapper);
If you implement this interface, the change is backwards incompatible. An implementation of HandleHandle, it is to expose the libraries functionality. It is made against 2.2.2 will not compile against this. On the other hand, the intent of the library is not for people to implement almost a header file. So, 2.3 or 3.0? "
It's 3.0. Semantics of what we mean by "API" aside, jDBI here is closer to an 'SPI', structurally it's not going to compile. That's how Java rolls. Fwiw, I think is a good example of where not to use an Interface rather than get into distinctions about public v published. I understand not programming to interfaces is heresy, but in this case I wouldn't care much - an abstract class will avoid uneccessary versioning pain.
I guess other people can ponder on what the generics are getting you there ;)
1 Comment
I think you are right about the class/interface thing, btw. The SPI angle is good, it is unintentional -- the interface is intended to make mocking easier to fake out talking to a DB, etc. An abstract class could do the job as well and make compat clearer.
The generics, in this case, are a noisy way to get something back from the mapper without a cast. Regardless of liking the amount of syntactic redundancy in Java, it does "work" :-)
*sigh*