Knut Anders Hatlen wrote:
Andreas Korneliussen <[EMAIL PROTECTED]> writes:
This is very interesting.
However, isn't it the job of the compiler to figure out that the
signatures of an interface has been implemented ?
I did the following change to EmbedResultSet40:
I added "implements java.sql.ResultSet" in the class definition. The
compilation then failed with:
[javac]
/home/ak136785/devel/derbydev/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedResultSet40.java:33:
org.apache.derby.impl.jdbc.EmbedResultSet40 is not abstract and
does not override abstract method
updateNCharacterStream(java.lang.String,java.io.Reader,int) in
java.sql.ResultSet
.. + warnings
The base class of EmbedResultSet40 also claims that it implements
java.sql.ResultSet, however it is compiled against a previous jre
version which does not have the new methods. By declaring that the
EmbedResultSet40 class implements java.sql.ResultSet, I make the
compiler check that the class implements the interface when compiling
it with the 1.6 jre.
Yes, I have observed this too, and I agree that it is the job of the
compiler to check this. However, I think there are some good reasons
for having a test as well:
I agree that you should keep the test as well - at least as long as the
current model for reuse is kept.
1) Relying on the developers to include "implements java.sql.(...)"
in the subclasses is error-prone since the compiler doesn't
complain if it's missing.
It is less error-prone than not including it, however it does not solve
all problems.
2) There might be cases where we don't have a separate 4.0 class,
either because it's forgotten or because the new JDBC 4.0 methods
could be compiled with older JDKs.
In such cases, one could make a separate class, which uses delegation to
reuse the JDBC 3 methods, and implements the JDBC 4 methods. The new
class should then be compiled against jdk1.6 rt.
3) Writing the test was a lot more fun than going through all
classes and adding "implements foo"! :)
I think it would be good for all EmbedXXX40 to declare which interface
they are supposed to implement, and then the compiler will make sure
that all signatures are satisfied.
+0.5
It might be a good idea, but it might also just give us a false sense
of security. For EmbedResultSet40 this would expose the errors, but it
wouldn't help us to find that something is missing in EmbedClob.
Yes, it would only solve parts of the problem, therefore I also suggest
changing the model to delegation, and to always make a new class if a
JDBC interface has been extended with new methods, and finally compile
the JDBC classes against the correct runtime libraries.
Andreas
Also, I think this also indicates that we should consider using
delegation instead of inheritance for code reuse.
+1
