It is not quite the same problem.
But it is unfortunately a real problem.
It will happen when interfaces get stuff added.
I guess the official solution is that a JDBC n.m compliant
JDBC driver must be compiled with a Java version at that
JDBC version and just run on the newest Java version.
But that is highly problematic in real world development
environments.
The alternative would be pretty ugly though:
public interface Statement40 extends Statement30
public interface Statement30 extends Statement20
public interface Statement20 extends Statement
You could imagine having language support for versioned interfaces, so
something like:
import java.sql.Statement;
public class LewsStatement implements Statement # 1.5 {
}
Or:
import java.sql.Statement # 1.5;
public class LewsStatement implements Statement {
}
Then elsewhere:
import java.sql.Statement # 1.4;
public class DatabaseProcessor {
public void Process(Statement stmt) ;
}
And as long as your class implements a version of Statement that's 1.4 or
later, it's a valid parameter. This is essentially syntactic sugar for
your 'ugly' code. It would require backward compatibility for subsequent
versions of an interface. I don't know for sure that this idea works -
we'd need a computer scientists to prove it, really.
Another option might be to have an abstract base class for implementing
the interface, which has concrete stubs for all the methods (which are
either no-op, delegate to other methods where possible, or throw
UnsupportedOperationException), so that as long as you extend that, you
conform to the interface even as it changes, because when the interface is
expanded, so is the base class. This isn't great, though, because the new
methods just have the base class implementations, and so will probably
fail in exciting and unhelpful ways at runtime. Plus, it constrains your
choice of base class.
tom
