Adding the implements java.sql.XXX should take care of detecting missing
methods in 4.0 classes. Delegating calls may be a safer way doing
things but it has practical problem take the case of EmbedConnection.
This class is being used in 102 different places in engine code.
I haven't seen all the uses but my assumption is that these classes will
be using internal methods of EmbedConnection (other wise they would have
been using java.sql.Connection). If EmbedConnection40 is not compatible
with EmbedConnection we will need a new interface which have all the
common non standard methods. And this problem will be even worse if in
every version of Connection there are some additional internal methods
used by other classes of the same version. We may end up having a
hierarchy of interface for each version.
Moving to delegation model may help catching the missing methods but I
don't think making a design decision in anticipation of programing
mistakes is a good idea.
anurag
interface
Andreas Korneliussen wrote On 03/28/06 17:54,:
Anurag Shekhar wrote:
Also, I think this also indicates that we should consider using
delegation instead of inheritance for code reuse.
Andreas
I didn't get it, how does it indicates that ?
anurag
Because now we are fooling the compiler to think that EmbedXXX40
classes implement java.sql.XXX interface since it inherits from a
class which has declared that it implements it. The problem is that
the base class is compiled against an old runtime library, and we lose
the compile time checks for the new methods.
This way of doing things was not introduced as part of JDBC4, it also
applies to JDBC3 vs JDBC2. So basically a developer may accidentally
change the signature of a JDBC3 method, and the compiler will not
complain. You will only detect the error in runtime, i.e through tests.
Andreas
