I think that this test is the gold-standard. It supplies a missing
sanity check which won't be available until we have a TCK for JDBC4.
Thanks for writing this test, Knut Anders.
Regards,
-Rick
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:
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.
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.
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.
Also, I think this also indicates that we should consider using
delegation instead of inheritance for code reuse.
+1
